Enable DMA mappings in vmwgfx after TTM has been fixed in commit
3bf3710e37 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
This enables full guest-backed memory support and in particular allows
usage of screen targets as the presentation mechanism.
Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
Reported-by: Ye Li <ye.li@broadcom.com>
Tested-by: Ye Li <ye.li@broadcom.com>
Fixes: 3b0d6458c7 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is active")
Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.6+
Reviewed-by: Martin Krastev <martin.krastev@broadcom.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240408022802.358641-1-zack.rusin@broadcom.com
Stop compiling vmenter.S with OBJECT_FILES_NON_STANDARD to skip objtool's
stack validation now that __svm_vcpu_run() and __svm_sev_es_vcpu_run()
create stack frames (though the former's effectiveness is dubious).
Note, due to a quirk in how OBJECT_FILES_NON_STANDARD was handled by the
build system prior to commit bf48d9b756 ("kbuild: change tool coverage
variables to take the path relative to $(obj)"), vmx/vmenter.S got lumped
in with svm/vmenter.S. __vmx_vcpu_run() already plays nice with frame
pointers, i.e. it was collateral damage when commit 7f4b5cde24 ("kvm:
Disable objtool frame pointer checking for vmenter.S") added the
OBJECT_FILES_NON_STANDARD hack-a-fix.
Link: https://lore.kernel.org/all/20240217055504.2059803-1-masahiroy@kernel.org
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20240223204233.3337324-9-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Now that KVM uses the host save area to context switch RBP, i.e.
preserves RBP for the entirety of __svm_sev_es_vcpu_run(), create a stack
frame using the standared FRAME_{BEGIN,END} macros.
Note, __svm_sev_es_vcpu_run() is subtly not a leaf function as it can call
into ibpb_feature() via UNTRAIN_RET_VM.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20240223204233.3337324-8-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Use the host save area to preserve volatile registers that are used in
__svm_sev_es_vcpu_run() to access function parameters after #VMEXIT.
Like saving/restoring non-volatile registers, there's no reason not to
take advantage of hardware restoring registers on #VMEXIT, as doing so
shaves a few instructions and the save area is going to be accessed no
matter what.
Converting all register save/restore code to use the host save area also
make it easier to follow the SEV-ES VMRUN flow in its entirety, as
opposed to having a mix of stack-based versus host save area save/restore.
Add a parameter to RESTORE_HOST_SPEC_CTRL_BODY so that the SEV-ES path
doesn't need to write @spec_ctrl_intercepted to memory just to play nice
with the common macro.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20240223204233.3337324-7-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Use the host save area to save/restore non-volatile (callee-saved)
registers in __svm_sev_es_vcpu_run() to take advantage of hardware loading
all registers from the save area on #VMEXIT. KVM still needs to save the
registers it wants restored, but the loads are handled automatically by
hardware.
Aside from less assembly code, letting hardware do the restoration means
stack frames are preserved for the entirety of __svm_sev_es_vcpu_run().
Opportunistically add a comment to call out why @svm needs to be saved
across VMRUN->#VMEXIT, as it's not easy to decipher that from the macro
hell.
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Cc: Alexey Kardashevskiy <aik@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20240223204233.3337324-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
POP @spec_ctrl_intercepted into RAX instead of RBX when discarding it from
the stack so that __svm_sev_es_vcpu_run() doesn't modify any non-volatile
registers. __svm_sev_es_vcpu_run() doesn't return a value, and RAX is
already are clobbered multiple times in the #VMEXIT path.
This will allowing using the host save area to save/restore non-volatile
registers in __svm_sev_es_vcpu_run().
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20240223204233.3337324-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Drop 32-bit "support" from __svm_sev_es_vcpu_run(), as SEV/SEV-ES firmly
64-bit only. The "support" was purely the result of bad copy+paste from
__svm_vcpu_run(), which in turn was slightly less bad copy+paste from
__vmx_vcpu_run().
Opportunistically convert to unadulterated register accesses so that it's
easier (but still not easy) to follow which registers hold what arguments,
and when.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20240223204233.3337324-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Compile (and link) __svm_sev_es_vcpu_run() if and only if SEV support is
actually enabled. This will allow dropping non-existent 32-bit "support"
from __svm_sev_es_vcpu_run() without causing undue confusion.
Intentionally don't provide a stub (but keep the declaration), as any sane
compiler, even with things like KASAN enabled, should eliminate the call
to __svm_sev_es_vcpu_run() since sev_es_guest() unconditionally returns
"false" if CONFIG_KVM_AMD_SEV=n.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20240223204233.3337324-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Unconditionally create a stack frame in __svm_vcpu_run() to play nice with
unwinding via frame pointers, at least until the point where RBP is loaded
with the guest's value. Don't bother conditioning the code on
CONFIG_FRAME_POINTER=y, as RBP needs to be saved and restored anyways (due
to it being clobbered with the guest's value); omitting the "MOV RSP, RBP"
is not worth the extra #ifdef.
Creating a stack frame will allow removing the OBJECT_FILES_NON_STANDARD
tag from vmenter.S once __svm_sev_es_vcpu_run() is fixed to not stomp all
over RBP for no reason.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20240223204233.3337324-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Remove KVM's unnecessary zeroing of memory when allocating the pages array
in sev_pin_memory() via __vmalloc(), as the array is only used to hold
kernel pointers. The kmalloc() path for "small" regions doesn't zero the
array, and if KVM leaks state and/or accesses uninitialized data, then the
kernel has bigger problems.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/c7619a3d3cbb36463531a7c73ccbde9db587986c.1710004509.git.christophe.jaillet@wanadoo.fr
[sean: massage changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Return struct xe_reg instead of reg.raw from xe_hwmon_get_reg
to have abstracted usage of struct xe_reg.
v2:
- Use xe_reg_is_valid function instead of XE_REG_IS_VALID macro
as it is removed.
Signed-off-by: Karthik Poosa <karthik.poosa@intel.com>
Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405130127.1392426-3-karthik.poosa@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Add a function to check if struct xe_reg has valid address.
v2:
- Rebase.
- Make xe_reg_is_valid as inline function instead of a macro. (Badal).
- Update commit msg.
Signed-off-by: Karthik Poosa <karthik.poosa@intel.com>
Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405130127.1392426-2-karthik.poosa@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
nouveau:
- regression fix for GSP display enable.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmYUtbQACgkQDHTzWXnE
hr6yng//YPGEzpYQ50Q1tKVFeLkB0TsZk+Hf874tbLu9kc2yQaez8/2s1iArSE6Y
la0DgZvwpdRxW2UI36x6pjuXL5og2aLcYh7SPtKVZn7903EXSzqOytkc9PQwRzvp
fAxXPQmj8xjZak05uhOHDG5XkPNrCzE37gRSygUn9TTlkRfnxWjEpBZMeeOEKZXq
O/pYhc49VsTLChGJvjeT0tzu2Nzo3EcZIwftaYpQmcGIrl1I3mYnS1GYDs9yO9WF
/4m+4z1haBQBr7cgo9ZbDH0DbdxZASVXukX50dq86Ppt6YevrROd92A8gd1k3Zol
B/APJdhh3zZNP8sNK/Gczj+oI5wq1/ECwFYzI8XoIe2mPXIKFWkU6sZtiuy21yGG
0ZgphDVp7tEuuxW9RiMz2+rmbIkn+NoxBmHkPwsV8xVRANxF1PywI4TWdfZhGrrm
4METGkJ5BtQ5blwqW1O5igILB9wT8qq0QdtDE7/8tAcUEVnPXmmB73wifDMVaEq8
4yZVNMpmP1d0Wu2oamrEEh99D8jHYqHB+WgRVoBD2eGPxiWqxED0s0SS3Klc2JQ/
LX6qctiHKUifk7S7g5qgC/QVlqUGDk8/Q3EGhUSuEMAmd6tMpxXNwfeg855pVsP+
Us+fJE4cC7argU0D5C7Yw9jK2lcgeXJMYbMyL4SFssAAMMHTYAs=
=pPLP
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2024-04-09' of https://gitlab.freedesktop.org/drm/kernel
Pull drm nouveau fix from Dave Airlie:
"A previous fix to nouveau devinit on the GSP paths fixed the Turing
but broke Ampere, I did some more digging and found the proper fix.
Sending it early as I want to make sure it makes the next 6.8 stable
kernels to fix the regression.
Regular fixes will be at end of week as usual.
nouveau:
- regression fix for GSP display enable"
* tag 'drm-fixes-2024-04-09' of https://gitlab.freedesktop.org/drm/kernel:
nouveau: fix devinit paths to only handle display on GSP.
check_timer_distribution() runs ten threads in a busy loop and tries to
test that the kernel distributes a process posix CPU timer signal to every
thread over time.
There is not guarantee that this is true even after commit bcb7ee7902
("posix-timers: Prefer delivery of signals to the current thread") because
that commit only avoids waking up the sleeping process leader thread, but
that has nothing to do with the actual signal delivery.
As the signal is process wide the first thread which observes sigpending
and wins the race to lock sighand will deliver the signal. Testing shows
that this hangs on a regular base because some threads never win the race.
The comment "This primarily tests that the kernel does not favour any one."
is wrong. The kernel does favour a thread which hits the timer interrupt
when CLOCK_PROCESS_CPUTIME_ID expires.
Rewrite the test so it only checks that the group leader sleeping in join()
never receives SIGALRM and the thread which burns CPU cycles receives all
signals.
In older kernels which do not have commit bcb7ee7902 ("posix-timers:
Prefer delivery of signals to the current thread") the test-case fails
immediately, the very 1st tick wakes the leader up. Otherwise it quickly
succeeds after 100 ticks.
CI testing wants to use newer selftest versions on stable kernels. In this
case the test is guaranteed to fail.
So check in the failure case whether the kernel version is less than v6.3
and skip the test result in that case.
[ tglx: Massaged change log, renamed the version check helper ]
Fixes: e797203fb3 ("selftests/timers/posix_timers: Test delivery of signals across threads")
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240409133802.GD29396@redhat.com
The ChipID bytes are read in inverse order: invert the ChipID value
defined as IT5205FN_CHIP_ID and used for validating the same.
Fixes: 41fe9ea169 ("usb: typec: mux: Add ITE IT5205 Alternate Mode Passive MUX driver")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20240409113646.305105-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When sending a patch to (among others) Li Yang the nxp MTA replied that
the address doesn't exist and so the mail couldn't be delivered. The
error code was 550, so at least technically that's not a temporal issue.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240405072042.697182-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a small helper to compute the set of pipes that the current
crtc is using.
And we have at least one trivial place in
intel_ddi_update_active_dpll() where we can use it
immediately, so let's do that.
v2: Use the name 'pipe_crtc' for the per-pipe crtc pointer
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-12-ville.syrjala@linux.intel.com
Pass the connector explicitly to intel_dp_need_bigjoiner()
so that it'll actually check the correct place for the
bigjoiner force flag.
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-11-ville.syrjala@linux.intel.com
intel_dp_mst_compute_config() is missing the "does the
joiner need DSC?" check despite claiming to have a lot
of other joiner/dsc stuff in there (albeit disabled).
Replicate the logic from the SST side.
TODO: refactor all this duplicated code!
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-10-ville.syrjala@linux.intel.com
It turns out that while the QSEECOM APP_SEND command has specific fields
for request and response buffers, uefisecapp expects them both to be in
a single memory region. Failure to adhere to this has (so far) resulted
in either no response being written to the response buffer (causing an
EIO to be emitted down the line), the SCM call to fail with EINVAL
(i.e., directly from TZ/firmware), or the device to be hard-reset.
While this issue can be triggered deterministically, in the current form
it seems to happen rather sporadically (which is why it has gone
unnoticed during earlier testing). This is likely due to the two
kzalloc() calls (for request and response) being directly after each
other. Which means that those likely return consecutive regions most of
the time, especially when not much else is going on in the system.
Fix this by allocating a single memory region for both request and
response buffers, properly aligning both structs inside it. This
unfortunately also means that the qcom_scm_qseecom_app_send() interface
needs to be restructured, as it should no longer map the DMA regions
separately. Therefore, move the responsibility of DMA allocation (or
mapping) to the caller.
Fixes: 759e7a2b62 ("firmware: Add support for Qualcomm UEFI Secure Application")
Cc: stable@vger.kernel.org # 6.7
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # X13s
Link: https://lore.kernel.org/r/20240406130125.1047436-1-luzmaximilian@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The circular buffer is NULLified in uart_tty_port_shutdown()
under the spin lock. However, the PM or other timer based callbacks
may still trigger after this event without knowning that buffer pointer
is not valid. Since the serial code is a bit inconsistent in checking
the buffer state (some rely on the head-tail positions, some on the
buffer pointer), it's better to have both aligned, i.e. buffer pointer
to be NULL and head-tail possitions to be the same, meaning it's empty.
This will prevent asynchronous calls to dereference NULL pointer as
reported recently in 8250 case:
BUG: kernel NULL pointer dereference, address: 00000cf5
Workqueue: pm pm_runtime_work
EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)
...
? serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)
__start_tx (drivers/tty/serial/8250/8250_port.c:1551)
serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654)
serial_port_runtime_suspend (include/linux/serial_core.h:667 drivers/tty/serial/serial_port.c:63)
__rpm_callback (drivers/base/power/runtime.c:393)
? serial_port_remove (drivers/tty/serial/serial_port.c:50)
rpm_suspend (drivers/base/power/runtime.c:447)
The proposed change will prevent ->start_tx() to be called during
suspend on shut down port.
Fixes: 43066e3222 ("serial: port: Don't suspend if the port is still busy")
Cc: stable <stable@kernel.org>
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202404031607.2e92eebe-lkp@intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240404150034.41648-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
thread_info.syscall is used by syscall_get_nr to supply syscall nr
over a thread stack frame.
Previously, thread_info.syscall is only saved at syscall_trace_enter
when syscall tracing is enabled. However rest of the kernel code do
expect syscall_get_nr to be available without syscall tracing. The
previous design breaks collect_syscall.
Move saving process to syscall entry to fix it.
Reported-by: Xi Ruoyao <xry111@xry111.site>
Link: https://github.com/util-linux/util-linux/issues/2867
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
If the "bootconfig" kernel command-line argument was specified or if
the kernel was built with CONFIG_BOOT_CONFIG_FORCE, but if there are
no embedded kernel parameter, omit the "# Parameters from bootloader:"
comment from the /proc/bootconfig file. This will cause automation
to fall back to the /proc/cmdline file, which will be identical to the
comment in this no-embedded-kernel-parameters case.
Link: https://lore.kernel.org/all/20240409044358.1156477-2-paulmck@kernel.org/
Fixes: 8b8ce6c75430 ("fs/proc: remove redundant comments from /proc/bootconfig")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: stable@vger.kernel.org
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
A fix for the ccache driver which no longer probed after the PLIC driver
was converted to a platform driver. The JH7100 SoC depends on this
driver to provide cache management ops that must be registered with an
arch_initcall, so the ccache driver is partly converted to a platform
driver, registering only the cache management ops with the initcall and
the debug/edac register provision features of the driver as a platform
driver.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZhEeLQAKCRB4tDGHoIJi
0jdgAP0X6EECKhObfIXHP7uJFafYQA5UKBOgNZrA/N/VXxCDiQEAhZOz/2bq0EZu
RN8ZIjF+bV9yDPulcS9IHMJlLNw/RQg=
=F2ys
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYVUQEACgkQYKtH/8kJ
UidY/BAAjmX79pSrujbZ0lwru9qqA4TYLbNq2Uy0CrEAadYWZXlmRKIRcNYVxi8U
kUCPycJ5H1nnIKtuVTqn6albpRvtIUUAqfNwBzABNPyrnAYumCYPmCvyCgO04WxG
alHEfaf7fRG+6M7Il1G4xTf6NXsdEGE96V+E0TFPfqlyQGpoVarUlydyTFyoCvDG
FMNAdQkGWm5oJFGTroe5XqP/XHtgJ+oOArWqdSn5cA5Hly/L3vGhsC2O6FEw4LQm
GC+GKCGN85oURHM7qLzSY1PP1toUMIfU2Mh1TA9k2BvSmye9xHY+L5iyAga6qr3h
ff4hWWu0QTiJfqOU0DjuOARAiSocBgPEg66tSs0q/jcOZCNjm3Hxq5HMx10bDfes
3TskcxeDsMLlqIxEnJXrzzSrDfpqJARBjvoYB3AOaLthxPGcv9StYlJYRAaFLG3Y
d4NyNWTahBGu5HA1Z7Vzql44F9OG6Kiw/mDYUgu8kqKc/hN6Z56tjm5zSZFD/fn/
aKQ6fxuf1Ed7hK3UT2Iq7RJtB/aMXTpq5MmsNEf3s/5bpCUe8369kuc6O4HDJ2jZ
nlH7iwg80bLIgYcaaBGo0rydlP/KPzHDJQLMJzBuyfz0jsJhkXW5HZTblUOIxvIA
0ql5STW2pNFspUOR0gcR0YVPxwh2Gub0ZLQw7ISEzh6BpWpZdps=
=PJbD
-----END PGP SIGNATURE-----
Merge tag 'riscv-soc-fixes-for-v6.9-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes
RISC-V SoC driver fixes for v6.9-rc3
A fix for the ccache driver which no longer probed after the PLIC driver
was converted to a platform driver. The JH7100 SoC depends on this
driver to provide cache management ops that must be registered with an
arch_initcall, so the ccache driver is partly converted to a platform
driver, registering only the cache management ops with the initcall and
the debug/edac register provision features of the driver as a platform
driver.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
* tag 'riscv-soc-fixes-for-v6.9-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
cache: sifive_ccache: Partially convert to a platform driver
Link: https://lore.kernel.org/r/20240406-botch-disband-efc69b8236be@spud
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A single fix to address the incorrect check of VM ID count for the
global notification in the response received for FFA_NOTIFICATION_INFO_GET()
in the schedule receiver interrupt handler.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmYOsEQACgkQAEG6vDF+
4pj40hAAnQYDZP6yBeYCEoAb2EVNRPCJvJGeP4UroYn5ZErUr/GPKj5DGvXRFwno
K4DwLNElBhwwhqNO0wR5U82lmXyl+hCM/Kl2p2KFHaWIa/6aLNI2G2ohKFbZorqy
jY/i+a7P7HydOiFUOl4VJTUEYAT9W4HIvOucKBLq7DcOiEHgjasT+2JcyHBOgdvb
boxVAfK4LKPvqBiXaZp/eZbPhcrrB0HghkepugnHgJUsiLMXPOJNqD0XgUQhSG/g
z3UKxdBBzgTtlKrAvceuKqF97PWcZBXskr5FL00LjR+Gf6U35nWrG3fkes+Ceflh
7NR8ED8Ri2EwBAaqHyiYmqZswsRctwn+8GRUDZEzH0YdWWXs9T7dIYpyChfYBDyD
bdsYvIJR9HdM8dV2cv27w6QcQqpyPLHW9+htzO3g4RBNyhDJPaV9JX5bau0UBeWj
U0wUwUY1OotfV9eXiT8DoHQosgGtvyNfL5dr+q8bI66VWGvZl7/dlO3v7w/uI8WQ
0asJKTSkxPpDoOgFlNSzdf0zenF0ifKfP3OKj2LMNtel4KTgkr3ou30OwTbcIAJp
K1SjQe0mmWMK1jTuAphhk43EjdVFX/Kqj8Zg7GHZfF1zLuv17ZQBPHHnrxnyhdEW
3zmPKuo+NhKc6ADyL2MHVpR0WboPv9+oAufGeHzC/g+bz7VQuxI=
=cVg4
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYVUNwACgkQYKtH/8kJ
UieKDRAA4PPStD8HpQO1YL2or0roqG4mIJkD1G2CCYbYn4iZngOp+d3FoVS7AIhu
MoaDDZ3YC42vqoYIB/+/2Eu11cOfSKNcFiSencGYKlMJKu2+pUzPK9nkgKw2LzD3
AFTsY3AO0Ww5YQnwOZvuy2DRPfXkqgPS3jefw6VR1aICukR/giLzDQ8oDo/mEGMk
cr89aXD5NvF76WzhHjIeKEg45SeeMRS55GvQFmVtADcg+j/uSxMR1EVh/yeWuOfR
UPmyg+4nT83gvVtHrub51Hra9oW1VmoA5tyNRUe4QsHaObcfpDOlFDheJXl7MSZp
DDAscGN6C+mgjQp362PoqkPAP+kloGxmCwKX4+e1ROiWf92558DXxSq/ohXwcgFz
tEGWiQPYoiZuiEZOjqnNqi16vZa/NwiCAnomj2kUX5eQm4qLnzLrtcejBgcRrvUq
P7i3GZdLtXcGsLNo8AWIYE4z5xiOa+2WV6r+AWGeNo4R5RsyNB1AQtjS5mxTYoB/
3+zVFK8+CfQuX1AyOI8oc8mUigBItiHhuyvDAEdTWVgdcsjHmAaNMDVP+pFpsX1J
EWSogIvVuYvmLE6jy0GPHCvzKCKwXK3oNYBN3VpdzHKaqv1V91RSgJXTuKSioDm6
LvgbsJsiJS9k226xqbscuEZy5+ri7UvjYYBvJSpXoYKkHgkPcVU=
=NSXv
-----END PGP SIGNATURE-----
Merge tag 'ffa-fix-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm FF-A fix for v6.9
A single fix to address the incorrect check of VM ID count for the
global notification in the response received for FFA_NOTIFICATION_INFO_GET()
in the schedule receiver interrupt handler.
* tag 'ffa-fix-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Fix the partition ID check in ffa_notification_info_get()
Link: https://lore.kernel.org/r/20240404140339.450509-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Couple of fixes to address wrong fastchannel initialization in powercap
protocol and disable seeking support for SCMI raw debugfs entries.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmYOsRYACgkQAEG6vDF+
4pja7RAAipMbP9g1qC0kRV8kgCF7k+yT8Lrx9E4HAdCbdSLFD5OMelxUX3p6HMG5
lF7c1N6OdqQ6UH5WIeKPJpg2QpPHO0vCVhkXWeowuVVGxLelp+iTeAHTpzS0xpdr
f9UIx/2NnlOx/Pv6hiHTIbP1MSv4b49o/S7Qi3CJoNc5Oa/1A/bRENos7OkuPq2+
pVygp8h1IduFjaBqY8/eZw01n+W0oepDF8iMbykW/rS6ww/B27mcKqla6yYLHOl+
i66HVwAqRxR/TPOQePflROJBc8dw+DFAqaqtU4VMrSwlBIPoZ6wmuv44H+Y4tIKn
RTtoDG1M854SSgqfQmk4/blWcw2r4RoxO8BlfoqvLvwAHBfF3NLG4YPBTyeESVHN
53TT8zMeHr/dHMRjHBzUJRQrrwI2LPMOVcqFnZIWQSBvqBfFEUAm4GxcgT7L2h5l
3xaJWd237tFegaNmTAcd7oBqMQD1/4FXLLFI9gCoCqQEPaUzol5bx/u6i58wK6il
Y7cnER2VhyrqPxc+1T3NYyUFwY/TAIlkTtqAp73YQOnv60EttHSie/KJvfW2BkeK
bUnCwhZFTwfmIHUU/hpWEDnna0gUz6FsqgjS4SOE70FZNeV3CvU9o9vkGbWjYgSE
XrcalwoEQodpF65dXX2wPjtOhQXYlGHB2Ixl9EwL9LxvlrTLy9A=
=iYDI
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYVTxsACgkQYKtH/8kJ
Uif2ExAAn0h30qQzEk4UN3Cvk+lXPqbjSDRPDb7IXWqF1Sdu7JqSf47EJWnOzURD
113FPynqxnPWppzHFmVmqLM+hO7uj17d5QQglKitS1VZ+Vv0nRUYe7N76g5eUKcA
j3x2DZOTy0zT4bcXv0tiGSu35wo74yg2q7c/e7FHhtNC81cUYdp25SUNptrNgq/1
iPZpRRJ+/Z0WFXVBXPtnQpbXmecFbApWuKZbE5YbotR7FCDNwxH57IlVJqIj2BzY
fcpbSrywSBN320wU0+8SWnfUj5y9V6cBEtrIAZ6u/0AyZ9PMYZcacWJuORBatgzw
fQjvpE0Rqm6ekYerC+zf1okKG4uhac8b1NbL+KSa38ymnKtNL174eIRj9OR5grN3
nOs0rv7i97mqpu0quzhZZ+WADXEk/dH7Gzubl2F7K1Gd1voXrTjUhsDFGeSlZlUW
4oCcnGpeuV7EZOZG5lftQ3SeRoahzq64tomUjVQNBrrmvkiQYR1FwoY3JRyM2FyG
AzNFCwA6DgsmoTTuyj61xeEGTE2LIwkkZ3G1vWKmSbA2QVvmOeOB8L9NjCWtwWfo
FA0p3W7XRLvgxxkzc+2X06EoHUQDEa5tBuiEYcoJz0YIp6IBzHubgyJfVrAtZKKw
fecmwNu74A33M1QPoMdEQhEK5Kmf6hNeUQDKdK/5CCcosr7kcdw=
=4cp1
-----END PGP SIGNATURE-----
Merge tag 'scmi-fixes-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm SCMI fixes for v6.9
Couple of fixes to address wrong fastchannel initialization in powercap
protocol and disable seeking support for SCMI raw debugfs entries.
* tag 'scmi-fixes-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Make raw debugfs entries non-seekable
firmware: arm_scmi: Fix wrong fastchannel initialization
Link: https://lore.kernel.org/r/20240404140306.450330-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- A couple of i.MX7 board fixes from Fabio Estevam that use correct
'no-mmc' property and pass 'link-frequencies' for OV2680.
- A series from Frank Li to fix LPCG clock indices for i.MX8 subsystems.
- A couple of changes from Tim Harvey that fix USB VBUS regulator for
imx8mp-venice board.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmYOakUUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM6TJwf9FXjyq5/iqt84oXWhOcYN5GfxkJ6x
7PoVEHk2YlGX1kyPLVZaQuHn9ABJdOvcALZKCjTJjresEkg61or1PCFUBE+rOqeb
0U5u005M073EdkkRzn2Fn1mDqIhWxNfCJ5N4wigTz985PqjEe3evjjL/Y1T8MXOG
Is4S+1g2imjwKJq6zLsre4QpO74Zi8cJHjoxPZMcmNIYoPHXoancNneuNQyTgGt4
YBpo5W1LwUQMBo5rstNdjELwbI5xfxrXsVBuW4XqQGd39BPDkX+IqXFPUH6atuH5
46v7atL+1vEiPWCkbxCE98/11VcW8UYh1njvdDP0O4bh66SEhjKHRm1NUw==
=2zFX
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYVTs0ACgkQYKtH/8kJ
Uid4Vw//Si4Cw7yk9xe4xFXI7pYf46Cpgmg4Q75F8x6mJvy0jtYqIOFhwJH5INFj
Ry9EpvhYUkO7kGxe7OIE+m1hiY92Vcf9LFgnHkAaEed/gf47aTy+3Zougs9/ennN
0JbdxROK3P2nBWCIiVxDKtykMy7k9ZJlEZqGaof5icWlNPrirXzg7MO1hv33dMyR
fjQJKO2OOXNMUob6SJMJww7bkO5N5JjwsrD4U+FUOoPvbwfmWfI7bc5hMzmu89il
IwMxOcXrgkkUmCSO5KfGxjBTfMwxTHwRyk82iGU2b1sEXuBNBbMCbWKd6r42C91n
WF/4NFNIFdMawywa8bVAaHIrFw062vhXsgxruxUzKt1erwl7EwZa4sAPFGmtFQG+
3Itlf/pMb693l4DQRTqs/Q9qJsz2+TaD+SixiQ888aNCb5iLavX8rD2MdERLeuHo
nf64UGRjTlSw2y4ekBvwcsMHME1f76H3LY2ESW1oGlJj8q4tBML6jDqeIp4rC98K
XqWy/9IAlHSWRcFc+U0ED8DGlLIvrrskoPZG3dpe7qb+l1roJowefqp0FzHno93K
r7N2ZgEHPcb9qYbgvYJd4VYZ6A0ZqTyxq24naPhJdYWYJKnvvqOoN2h2Y6Ml9waZ
I6mNDRQuJ210k8ile76Nnyu9BRRLqRDgExQ1ZZP9LeHjgg6eKbo=
=6Ly1
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 6.9:
- A couple of i.MX7 board fixes from Fabio Estevam that use correct
'no-mmc' property and pass 'link-frequencies' for OV2680.
- A series from Frank Li to fix LPCG clock indices for i.MX8 subsystems.
- A couple of changes from Tim Harvey that fix USB VBUS regulator for
imx8mp-venice board.
* tag 'imx-fixes-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: dts: imx8qm-ss-dma: fix can lpcg indices
arm64: dts: imx8-ss-dma: fix can lpcg indices
arm64: dts: imx8-ss-dma: fix adc lpcg indices
arm64: dts: imx8-ss-dma: fix pwm lpcg indices
arm64: dts: imx8-ss-dma: fix spi lpcg indices
arm64: dts: imx8-ss-conn: fix usb lpcg indices
arm64: dts: imx8-ss-lsio: fix pwm lpcg indices
ARM: dts: imx7s-warp: Pass OV2680 link-frequencies
ARM: dts: imx7-mba7: Use 'no-mmc' property
arm64: dts: imx8-ss-conn: fix usdhc wrong lpcg clock order
arm64: dts: freescale: imx8mp-venice-gw73xx-2x: fix USB vbus regulator
arm64: dts: freescale: imx8mp-venice-gw72xx-2x: fix USB vbus regulator
Link: https://lore.kernel.org/r/Zg5rfaVVvD9egoBK@dragon
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A series of fixes for n8x0 GPIO regressions caused by the changes to use
GPIO descriptors.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAmYNHfIRHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXOMJw/8Cdkb5dqmEur/qYK70eUE73tN6ytvncaH
HKzPkK3251Me/zz4+iEdyEHLfKGLmVCIAYjlfVOFxmMwBLJXgg3mUmQl2n1sfaJm
k26EkjBBcrH1ZscLoUv7J2LmRrexWOcU2LrHvaCMvuSw6O+fvk63nu6Xn9Lm+0V6
00PR22x7FHJVKllglhcfm+gcxFNKAwCfKitRBIPC+jDirsdj91W1L0vP5FL9qt2E
0INfpoFr4H8IhHezOuY+i4uYuaFiazzn2usL5CaDR+7g+wsDY/oP1TBXjidWMVEY
3VPiO/h//u7jhUKvrul+I2bZN8DUPSBt5TPImXGvBfTwRVM2pJWUzTVcrAXB4BV9
qx32rC1s0wUHSbit2d5vECjjO90xQrLLwWwfegQ7M1ALi5ZFKBEU2wq6GTMKkiQn
7bleU4Dq64hqYA7klhHdSfhkXxfWLuS+3DOBRIYbZk468HoRtNrLWGJ5SoXURB8B
1/wri5YarrDeo2J9J/AAentoQQyVJKvNpNBqPeEzGZApX0M/L0oKHSGqAQBZLTi2
ooiRXjSNprh4sD+e1JiLwl7stqITAVtLksGLt99ZN7QZN76Sk661FF5RtqmCP+QG
+kqildZALwVCO1qSe3q5Mboy/FxxQSdcg2+eKKK8kKIybqG7B/YTQMS30uPQNuTs
QdmnSLuHqdA=
=pHnd
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYVTgEACgkQYKtH/8kJ
UiethRAAjH6U7D1G4FjlixHcgkfLaunDCMjzqYqFLD0StMEz9yJ5wmADtO62Xsrz
gH4dMjD0+5UOS4ogs6rsfq7QcKVE9Wy7RocbFw0ZyBQquL6+AAcDKTgWQGYOpJ0L
9pAqgg/mBBgud+uk8B7nPt9qwTudQPKx6Ibj59UDwRfEoayYmu3X8t3qvVbO8ZOf
nEjTsrZ43fceWE+0mODBBX5OKd2Vv6qZQH+w+ZTKymEfxvEw3VjoCZ/4KDW3JZq4
e9eP0l8rdyjzwk709Eu1KDRkzXQLNBD0DIZUxXeyiNV2bE/nP/UUKk1lzgVhlvKZ
mxHywXbLn9lR0Nmmdgu2opj0UvVBBKOSnJ4//f1TjRGx1SMDBmqHHFZ8YNAl7SJj
1tDvxJI/pGYOK+BqU9Pj821wrTxjNzVedGTU6VCYyGn/r8OWbjVyOOMr01tI5LGK
IDZ7mPeGaDQGk4bWRtACXzfBbm+HgHE3nUAzoZY9DszXi5/JaxOySAKiIq3X0LQT
1dXfvCEX/p8GmNSCzlbavu9ucuDdNgNUXH6II3HszSLDZpDs7gt7DBkbkJ5w/rRt
Exgstlv5xoolzYHdmD1XUfufsOPbSjHySLhqp2nTrjYKPsBRggP/dIzH+UFaCTSN
ythuAm8i5MXyIOgZscPJGTH8aHSowp9DsX/x7a8luKRagiX4sh0=
=m+W/
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v6.9/n8x0-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes
GPIO regression fixes for n8x0
A series of fixes for n8x0 GPIO regressions caused by the changes to use
GPIO descriptors.
* tag 'omap-for-v6.9/n8x0-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: fix USB regression on Nokia N8x0
mmc: omap: restore original power up/down steps
mmc: omap: fix deferred probe
mmc: omap: fix broken slot switch lookup
ARM: OMAP2+: fix N810 MMC gpiod table
ARM: OMAP2+: fix bogus MMC GPIO labels on Nokia N8x0
Link: https://lore.kernel.org/r/pull-1712135932-125424@atomide.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I'm working now at bootlin, so I'll use my bootlin address for kernel
development from now on.
Update also the yaml file for atmel-serial accordingly.
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Reviewed-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20240408101329.9448-1-richard.genoud@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The mitigation was intended to stop the irq completely. That may be
better than a hard lock-up but it turns out that you get a crash anyway
if you're using pmac_zilog as a serial console:
ttyPZ0: pmz: rx irq flood !
BUG: spinlock recursion on CPU#0, swapper/0
That's because the pr_err() call in pmz_receive_chars() results in
pmz_console_write() attempting to lock a spinlock already locked in
pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal
BUG splat. The spinlock in question is the one in struct uart_port.
Even when it's not fatal, the serial port rx function ceases to work.
Also, the iteration limit doesn't play nicely with QEMU, as can be
seen in the bug report linked below.
A web search for other reports of the error message "pmz: rx irq flood"
didn't produce anything. So I don't think this code is needed any more.
Remove it.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: stable@kernel.org
Cc: linux-m68k@lists.linux-m68k.org
Link: https://github.com/vivier/qemu-m68k/issues/44
Link: https://lore.kernel.org/all/1078874617.9746.36.camel@gaston/
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable <stable@kernel.org>
Signed-off-by: Finn Thain <fthain@linux-m68k.org>
Link: https://lore.kernel.org/r/e853cf2c762f23101cd2ddec0cc0c2be0e72685f.1712568223.git.fthain@linux-m68k.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Driver complains that PCI IDs are not needed for some of the LAVA cards:
[ 0.297252] serial 0000:04:00.0: Redundant entry in serial pci_table.
[ 0.297252] Please send the output of lspci -vv, this
[ 0.297252] message (0x1407,0x0120,0x0000,0x0000), the
[ 0.297252] manufacturer and name of serial board or
[ 0.297252] modem board to <linux-serial@vger.kernel.org>.
Do as suggested.
Reported-by: Jimmy A <jimand04@hotmail.com>
Closes: https://lore.kernel.org/r/VI1P194MB052751BE157EFE9CEAB75725CE362@VI1P194MB0527.EURP194.PROD.OUTLOOK.COM
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20240403224152.945099-1-andy.shevchenko@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 45a3a8ef81 ("serial: core: Revert checks for tx runtime PM state")
caused a regression for Sun Ultra 60 for the sunsab driver as reported by
Nick Bowler <nbowler@draconx.ca>.
We need to add back the check runtime PM enabled state for serial port
controller device, I wrongly assumed earlier we could just remove it.
Fixes: 45a3a8ef81 ("serial: core: Revert checks for tx runtime PM state")
Cc: stable <stable@kernel.org>
Reported-by: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20240325071649.27040-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The uart_handle_cts_change() function in serial_core expects the caller
to hold uport->lock. For example, I have seen the below kernel splat,
when the Bluetooth driver is loaded on an i.MX28 board.
[ 85.119255] ------------[ cut here ]------------
[ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
[ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
[ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
[ 85.151396] Hardware name: Freescale MXS (Device Tree)
[ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]
(...)
[ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
[ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
(...)
Cc: stable@vger.kernel.org
Fixes: 4d90bb147e ("serial: core: Document and assert lock requirements for irq helpers")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Emil Kronborg <emil.kronborg@protonmail.com>
Link: https://lore.kernel.org/r/20240320121530.11348-1-emil.kronborg@protonmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit e5d6bd25f9 ("serial: 8250_dw: Do not reclock if already at
correct rate") breaks the dw UARTs on Intel Bay Trail (BYT) and
Cherry Trail (CHT) SoCs.
Before this change the RTL8732BS Bluetooth HCI which is found
connected over the dw UART on both BYT and CHT boards works properly:
Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723
Bluetooth: hci0: RTL: rom_version status=0 version=1
Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_config-OBDA8723.bin
Bluetooth: hci0: RTL: cfg_sz 64, total sz 24508
Bluetooth: hci0: RTL: fw version 0x365d462e
where as after this change probing it fails:
Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723
Bluetooth: hci0: RTL: rom_version status=0 version=1
Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_config-OBDA8723.bin
Bluetooth: hci0: RTL: cfg_sz 64, total sz 24508
Bluetooth: hci0: command 0xfc20 tx timeout
Bluetooth: hci0: RTL: download fw command failed (-110)
Revert the changes to fix this regression.
Fixes: e5d6bd25f9 ("serial: 8250_dw: Do not reclock if already at correct rate")
Cc: stable@vger.kernel.org
Cc: Peter Collingbourne <pcc@google.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Peter Collingbourne <pcc@google.com>
Link: https://lore.kernel.org/r/20240317214123.34482-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Goto the clean up path to clean up a couple clocks before returning
on this error path.
Fixes: 0087b9e694 ("serial: 8250_lpc18xx: Switch to use uart_read_port_properties()")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/92646c10-e0b5-4117-a9ac-ce9987d33ce3@moroto.mountain
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The log_martians variable is only used in an #ifdef, causing a 'make W=1'
warning with gcc:
net/ipv4/route.c: In function 'ip_rt_send_redirect':
net/ipv4/route.c:880:13: error: variable 'log_martians' set but not used [-Werror=unused-but-set-variable]
Change the #ifdef to an equivalent IS_ENABLED() to let the compiler
see where the variable is used.
Fixes: 30038fc61a ("net: ip_rt_send_redirect() optimization")
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20240408074219.3030256-2-arnd@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When CONFIG_IPV6_SUBTREES is disabled, the only user is hidden, causing
a 'make W=1' warning:
net/ipv6/ip6_fib.c: In function 'fib6_add':
net/ipv6/ip6_fib.c:1388:32: error: variable 'pn' set but not used [-Werror=unused-but-set-variable]
Add another #ifdef around the variable declaration, matching the other
uses in this file.
Fixes: 66729e18df ("[IPV6] ROUTE: Make sure we have fn->leaf when adding a node on subtree.")
Link: https://lore.kernel.org/netdev/20240322131746.904943-1-arnd@kernel.org/
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20240408074219.3030256-1-arnd@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Enable GuC Wa_14019882105 to block interrupts during C6 flow
when the memory path has been blocked
v2: Make helper function generic and name it as
guc_waklv_enable_simple (John Harrison)
v3: Make warning descriptive (John Harrison)
v4: s/drm_WARN/xe_gt_WARN/ (Michal)
Cc: John Harrison <john.harrison@intel.com>
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405084231.3620848-3-badal.nilawar@intel.com
To prevent running out of bits, new workaround (w/a) enable flags are
being added via a KLV system instead of a 32 bit flags word.
v2: GuC version check > 70.10 is not needed as base line xe doesnot
support anything below < 70.19
v3: Use 64 bit ggtt address for future
compatibility (John Harrison/Daniele)
v4: %s/PAGE_SIZE/SZ_4K/ (Michal)
Cc: John Harrison <John.C.Harrison@intel.com>
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405084231.3620848-2-badal.nilawar@intel.com
These IOCTL commands should be implemented by setting attributes on the
superblock, rather than in the IOCTL hooks in struct file_operations.
By returning -ENOTTY instead of -ENOIOCTLCMD, we instruct the fs/ioctl.c
logic to return -ENOTTY immediately, rather than attempting to call
f_op->unlocked_ioctl() or f_op->compat_ioctl() as a fallback.
Why this is safe:
Before this change, fs/ioctl.c would unsuccessfully attempt calling the
IOCTL hooks, and then return -ENOTTY. By returning -ENOTTY directly, we
return the same error code immediately, but save ourselves the fallback
attempt.
Motivation:
This simplifies the logic for these IOCTL commands and lets us reason about
the side effects of these IOCTLs more easily. It will be possible to
permit these IOCTLs under LSM IOCTL policies, without having to worry about
them getting dispatched to problematic device drivers (which sometimes do
work before looking at the IOCTL command number).
Link: https://lore.kernel.org/all/cnwpkeovzbumhprco7q2c2y6zxzmxfpwpwe3tyy6c3gg2szgqd@vfzjaw5v5imr/
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: Darrick J. Wong <djwong@kernel.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20240405214040.101396-2-gnoack@google.com
Acked-by: Kent Overstreet <kent.overstreet@linux.dev>
Signed-off-by: Christian Brauner <brauner@kernel.org>
NIX SQ mode and link backpressure configuration is required for
all platforms. But in current driver this code is wrongly placed
under specific platform check. This patch fixes the issue by
moving the code out of platform check.
Fixes: 5d9b976d44 ("octeontx2-af: Support fixed transmit scheduler topology")
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Link: https://lore.kernel.org/r/20240408063643.26288-1-gakula@marvell.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
As per the GICv4.1 spec (Arm IHI 0069H, 5.3.19):
"A VMAPP with {V, Alloc}=={0, x} is self-synchronizing, This means the ITS
command queue does not show the command as consumed until all of its
effects are completed."
Furthermore, VSYNC is allowed to deliver an SError when referencing a
non existent VPE.
By these definitions, a VMAPP followed by a VSYNC is a bug, as the
later references a VPE that has been unmapped by the former.
Fix it by eliding the VSYNC in this scenario.
Fixes: 64edfaa9a2 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP")
Signed-off-by: Nianyao Tang <tangnianyao@huawei.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Link: https://lore.kernel.org/r/20240406022737.3898763-1-tangnianyao@huawei.com
Prefer common check_add_overflow() from overflow.h over the locally
rolled versions of it. While check_add_overflow() does require a
variable to assign to, unlike add_overflows_t(), it's still better than
having multiple versions around.
Cc: Kees Cook <keescook@chromium.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405202625.2525671-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
