Nathan reported [1] that when built with clang, the um kernel
crashes pretty much immediately. This turned out to be an issue
with the inline assembly I had added, when clang used %rax/%eax
for both operands. Reorder it so current->thread.segv_continue
is written first, and then the lifetime of _faulted won't have
overlap with the lifetime of segv_continue.
In the email thread Benjamin also pointed out that current->mm
is only NULL for true kernel tasks, but we could do this for a
userspace task, so the current->thread.segv_continue logic must
be lifted out of the mm==NULL check.
Finally, while looking at this, put a barrier() so the NULL
assignment to thread.segv_continue cannot be reorder before
the possibly faulting operation.
Reported-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://lore.kernel.org/r/20250402221254.GA384@ax162 [1]
Fixes: d1d7f01f7c ("um: mark rodata read-only and implement _nofault accesses")
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The "media: atomisp: Add support for sensors with a separate ISP
v4l2_subdev" combined with some pending drivers/media/i2c/mt9m114.c changes
makes the atomisp work nicely with the standard V4L2 mt9m114.c driver,
avoiding the need for the atomisp specific atomisp-mt9m114 driver.
The normal driver actually works better since the atomisp-mt9m114 driver
does not have working exposure control, leading to a much too dark image.
Remove the no longer necessary atomisp-mt9m114 driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Some sensors have an ISP inside the sensor which the sensor driver models
as a separate v4l2-subdev, like the mt9m114 sensor-driver does.
Since the atomisp driver emulates a standard /dev/video# v4l2-device
without requiring the application to be aware of media-controller centric
/dev/video# devices this requires some special handling in the driver.
Add support for this setup to the atomisp driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When a (sensor) v4l2_subdev has its state_lock member set to non NULL,
then all v4l2_subdev_state-s for the sensor share the same lock.
atomisp_init_sensor() calls v4l2_subdev_lock_and_get_active_state() and
then later on also tries to lock a separate v4l2_subdev_state used for try
calls (rather then changing the active state), while still holding
the active state lock.
Since this try v4l2_subdev_state shares a lock with the active state this
results in a deadlock.
Skip locking try_sd_state when sensor->state_lock is set to avoid this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The camera v4l2_subdev pointer in struct atomisp_input_subdev points to
an image sensor, rename camera to sensor to make this more clear.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The atomisp_compat_ioctl32() function was deleted in commit b4c650f1af
("media: atomisp: remove compat_ioctl32 code"), so this header file is no
longer needed.
Additionally, the definition of atomisp_compat_ioctl32() in atomisp_ioctl.h
is unused as well. Delete the declaration from the header.
Signed-off-by: Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250421052804.11721-1-hardevsinh.palaniya@siliconsignals.io
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When a value has been tested for NULL in an expression, a
second NULL test on the same value in another expression
is unnecessary when the value has not been assigned NULL.
Remove unnecessary duplicate NULL tests on the same value that
has previously been NULL tested.
Found by Coccinelle.
Signed-off-by: Abraham Samuel Adekunle <abrahamadekunle50@gmail.com>
Link: https://lore.kernel.org/r/26990d4a9d4419f9d4155a40595bc213acb671a0.1743685415.git.abrahamadekunle50@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Replace spaces with TAB to comply with kernel coding style.
Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
Link: https://lore.kernel.org/r/20250407123608.366190-1-gshahrouzi@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fix the coefficients spelling error in ia_css_sdis2_types.h.
Signed-off-by: Liu Jing <liujing@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20241209064022.4342-1-liujing@cmss.chinamobile.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
hrt_isp_css_irq_sw_pin_0 has a different enum type than
irq_sw_channel_id_t.
Replace it with the actual value of hrt_isp_css_irq_sw_pin_0 to avoid
arithmetic operations between different enum types (and make the
compiler happy).
It is required to build with llvm 19 without these warnings:
.../sh_css_hrt.c:68:19: warning: arithmetic between different enumeration types ('irq_sw_channel_id_t' and 'enum hrt_isp_css_irq') [-Wenum-enum-conversion]
.../sh_css.c:1233:40: warning: arithmetic between different enumeration types ('irq_sw_channel_id_t' and 'enum hrt_isp_css_irq') [-Wenum-enum-conversion]
.../sh_css.c:1237:40: warning: arithmetic between different enumeration types ('irq_sw_channel_id_t' and 'enum hrt_isp_css_irq') [-Wenum-enum-conversion]
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Link: https://lore.kernel.org/r/20241202-fix-llvm9-v1-2-2a50f5acfd0b@chromium.org
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
atomisp_try_fmt() is limiting the width of the requested resolution to 1920
before calling the sensor's try_fmt() method. But it is not limiting
the height. In case of the old mode-list based t4ka3 driver which has
a mode list of:
736x496
896x736
1936x1096
3280x2464
This results in 3280x2464 being selected when try_fmt is called
with a requested resolution of 3280x2464, which is not supported because
its width > 1920 .
Fix this by also limiting the height when in preview mode.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20241211173516.350779-1-hdegoede@redhat.com
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The GMIN code has support for sensors using external regulators enabled
by GPIOS, rather then using regulators build into the PMIC.
With the exception of the Trekstor ST70408-4 (1) tablet there are no known
devices which actually use external regulators for the sensors and the code
for this is using deprecated old style GPIO numbers support for which is
going away.
Remove the GPIO driven regulator support so that the gmin code no longer
depends on deprecated GPIO APIs.
1) The GMIN support itself is also deprecated and all sensor drivers still
using it are being moved over to use ACPI + runtime-pm and the ST70408-4
shipped with Android as factory OS and thus will have broken ACPI tables
for the sensors, so like other Android factory OS tablets it will need
a bespoke solution anyways.
Reported-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20241107221134.596149-1-hdegoede@redhat.com
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The Asus T100TA quirks set the same values as the defaults,
so they are not necessary. Remove them.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20241104123832.5539-1-hdegoede@redhat.com
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When running fstrim immediately after mounting a V4 filesystem,
the fstrim fails to trim all the free space in the filesystem. It
only trims the first extent in the by-size free space tree in each
AG and then returns. If a second fstrim is then run, it runs
correctly and the entire free space in the filesystem is iterated
and discarded correctly.
The problem lies in the setup of the trim cursor - it assumes that
pag->pagf_longest is valid without either reading the AGF first or
checking if xfs_perag_initialised_agf(pag) is true or not.
As a result, when a filesystem is mounted without reading the AGF
(e.g. a clean mount on a v4 filesystem) and the first operation is a
fstrim call, pag->pagf_longest is zero and so the free extent search
starts at the wrong end of the by-size btree and exits after
discarding the first record in the tree.
Fix this by deferring the initialisation of tcur->count to after
we have locked the AGF and guaranteed that the perag is properly
initialised. We trigger this on tcur->count == 0 after locking the
AGF, as this will only occur on the first call to
xfs_trim_gather_extents() for each AG. If we need to iterate,
tcur->count will be set to the length of the record we need to
restart at, so we can use this to ensure we only sample a valid
pag->pagf_longest value for the iteration.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Bill O'Donnell <bodonnel@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Fixes: 89cfa89960 ("xfs: reduce AGF hold times during fstrim operations")
Cc: <stable@vger.kernel.org> # v6.6
Signed-off-by: Carlos Maiolino <cem@kernel.org>
As has been done for various other algorithms, rework the design of the
SHA-256 library to support arch-optimized implementations, and make
crypto/sha256.c expose both generic and arch-optimized shash algorithms
that wrap the library functions.
This allows users of the SHA-256 library functions to take advantage of
the arch-optimized code, and this makes it much simpler to integrate
SHA-256 for each architecture.
Note that sha256_base.h is not used in the new design. It will be
removed once all the architecture-specific code has been updated.
Move the generic block function into its own module to avoid a circular
dependency from libsha256.ko => sha256-$ARCH.ko => libsha256.ko.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add export and import functions to maintain existing export format.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Now that every architecture provides a block function, use that
to implement the lib/poly1305 and remove the old per-arch code.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Since the poly1305 algorithm is fixed, there is no point in going
through the Crypto API for it. Use the lib/crypto poly1305 interface
instead.
For compatiblity keep the poly1305 parameter in the algorithm name.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add a block-only interface for poly1305. Implement the generic
code first.
Also use the generic partial block helper.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Extract the common partial block handling into a helper macro
that can be reused by other library code.
Also delete the unused sha256_base_do_finalize function.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Merge mainline to pick up bcachefs poly1305 patch 4bf4b5046d
("bcachefs: use library APIs for ChaCha20 and Poly1305"). This
is a prerequisite for removing the poly1305 shash algorithm.
Most of the SEV support code used to reside in a single C source file
that was included in two places: the core kernel, and the decompressor.
The code that is actually shared with the decompressor was moved into a
separate, shared source file under startup/, on the basis that the
decompressor also executes from the early 1:1 mapping of memory.
However, while the elaborate #VC handling and instruction decoding that
it involves is also performed by the decompressor, it does not actually
occur in the core kernel at early boot, and therefore, does not need to
be part of the confined early startup code.
So split off the #VC handling code and move it back into arch/x86/coco
where it came from, into another C source file that is included from
both the decompressor and the core kernel.
Code movement only - no functional change intended.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Kevin Loughlin <kevinloughlin@google.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-efi@vger.kernel.org
Link: https://lore.kernel.org/r/20250504095230.2932860-31-ardb+git@google.com
Dynamic Antenna Gain (DAG) adjusts TX power based on antenna gain. To
prevent signal distortion from excessive power increases, a dynamic
antenna power table limits the maximum adjustable TX power.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250430055157.13623-3-pkshih@realtek.com
Newer firmware will notify driver of the Packet Detection (PD)
value on the channel after switch channels during FW scan.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250430055157.13623-2-pkshih@realtek.com
Internally wiphy writes to individual channels in this structure,
so we must not share one static definition of channel list between
multiple device instances, because that causes hard to debug
breakage.
For example, with two rtw89 driven devices in the system, channel
information may get incoherent, preventing channel use.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250429122916.1734879-3-megi@xff.cz
The code can be simplified by using device managed memory
allocations. Simplify it.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250429122916.1734879-2-megi@xff.cz
A link bound to HW band 0 was previously always assumed to exist, because
it's true on non-MLD connection, and MLO connection is not supported yet.
Now, start to consider MLO cases and prepare to enable MLO support in the
following. Add skeleton of designated link. For single-link cases, helper
returns the one. For multi-link cases, priorities can be scheduled. Then,
drop assumption of link bound to HW band 0.
One exception is that MCC doesn't work with MLD yet, so it still expects
link on HW band 0 somewhere.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-11-pkshih@realtek.com
Originally, a macro, RTW89_ROC_BY_LINK_INDEX, is used to decide the link
which deals with the ROC process. Before enabling MLO support, it's fine
to hard-code RTW89_ROC_BY_LINK_INDEX as 0 since the link instance-0 (on
HW-0) is always active. But, for the impending enablement of MLO support,
tweak the leaf functions to dynamically handle ROC link instance index.
Besides, in the follow-up, ROC caller will get a designated link and will
then drop RTW89_ROC_BY_LINK_INDEX.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-10-pkshih@realtek.com
For MLO connections, RX link ID is required to do address conversion.
Fill it in by the hardware info.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-9-pkshih@realtek.com
Add MLD capabilities so association requests can carry multi-link
element with correct content.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-8-pkshih@realtek.com
The join_info H2C command is used to indicate a station is connected and
tell FW to create/maintain an instance for it. Extend to fill MLO fields.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-7-pkshih@realtek.com
Previously only the first band is used for scanning. With MLO, update
scan parameters accordingly by so we can choose to scan from either band.
C2H event return value reflects current scanning band, mask it out so
we don't treat correct return value as fail.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-6-pkshih@realtek.com
After impending MLO support, TX Qsel would come from other HW band rather
than HW-0. For example, when working on HW-1, TX release report may fill
QSEL_XX_1 and cause warning "Cannot map qsel to dma: ...". So, extend the
mapping to recognize multiple HW bands.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-5-pkshih@realtek.com
Adjust mapping of management packets accordingly to send it on the
second hardware band. Previously only single band is used and we
plan to enable MLO, so the second band will be needed. Data packets
will be steered by hardware so no related changes are required.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-4-pkshih@realtek.com
8922A doesn't support broadcast/multicast traffic under MLO mode.
So let mac80211 do the encryption/decryption for us when the
connection is in MLO mode. Future BE ICs fixes this issue.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-3-pkshih@realtek.com
The RX DCK in firmware could retry 3 times if calibration value is not
stable. Roughly each calibration can be done within 16 ms, so expect
16 * 4 (with additional 16 ms) will be enough. More, in coming MLO, it
will do calibration on two path, so multiply 2.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-2-pkshih@realtek.com
In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicitly cast to any pointer type.)
The assigned type is "struct rtw89_reg2_def *" but the returned type,
while technically matching, will be const qualified. As there isn't a
general way to discard "const" qualifiers, adjust the returned type to
match the assigned type. No change in allocation size results.
Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250426060935.work.049-kees@kernel.org
The last use of rtl_bb_delay() was removed in 2014's
commit 5c99f04fec ("rtlwifi: rtl8723be: Update driver to match Realtek
release of 06/28/14")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250425235340.288340-4-linux@treblig.org
rtl92d_phy_ap_calibrate(),
rtl92du_phy_ap_calibrate(),
rtl92ee_phy_ap_calibrate(), and
rtl8821ae_phy_ap_calibrate()
are all empty function stubs that are never called anywhere.
Remove them.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250425235340.288340-3-linux@treblig.org
rtl_usb_resume() and rtl_usb_suspend() are trivial stubs that were
added in 2011's
commit 2ca20f79e0 ("rtlwifi: Add usb driver")
but aren't wired up anywhere (though commit 442888c706 ("rtlwifi:
rtl8192cu: Add routines dm, fw, led and sw") added commented
out assignments).
Remove them.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250425235340.288340-2-linux@treblig.org
