This reverts commit b45605fac3 which is
commit 543841d1806029889c2f69f040e88b247aba8e22 upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: I22e4874caa735da68f10a3d6477069f24bc0462d
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 73e268b4be which is
commit 619af16b3b57a3a4ee50b9a30add9ff155541e71 upstream.
It breaks the Android kernel build and can be brought back in the future
in an safe way if it is really needed.
Bug: 161946584
Change-Id: Ice4a456e51817eb48fad85c2ae048a88338807ef
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 4953207927 which is
commit 4d27afbf256028a1f54363367f30efc8854433c3 upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: I6b743cfeb8ce98af2f957100d6a32ab4ea4bf515
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Steps on the way to 6.1.129
Resolves merge conflicts in:
drivers/usb/typec/tcpm/tcpci.c
drivers/usb/typec/tcpm/tcpm.c
Change-Id: Id20ff6e44155d868c2542d94a30131d8658800c2
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Steps on the way to 6.1.129
Resolves merge conflicts in:
drivers/usb/dwc3/core.c
Change-Id: I2c283da276b9179cd76403d2fa83da077615d0be
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Steps on the way to 6.1.129
Resolves merge conflicts in:
drivers/usb/host/xhci-ring.c
Change-Id: Ie123285eab89802392003b95ec495b21820ad41b
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Steps on the way to 6.1.129
Resolves merge conflicts in:
scripts/Makefile.lib
Change-Id: Id496f510e74b8576bd71449bf8ffa338072eb8e4
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 8f7cc7c763 which is
commit 8ac412a3361173e3000b16167af3d1f6f90af613 upstream.
It breaks the Android kernel build and can be brought back in the future
in an build-safe way if it is really needed.
Bug: 161946584
Change-Id: I150a126d974ab67537cdb11d1348441834b154c5
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 4dff070117 which is
commit 754833b319 upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: Iee1382014bb394455d5d39e5dee9a036e8988cae
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 92fcb46659 which is
commit 142e17c1c2 upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: I1af7c9d9e49c81fae8706dc5fcb1f80e5aaac0b0
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 7f73098bc6 which is
commit 5f756d03e2 upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: I2e361b5c7e9306d76e606eaa5eb1fa87af5eed28
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 7baa59f83f which is
commit a5893928bb upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: I00b677f975738c791bf7074c982a8e215f8054ac
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit e20fd4d3a4 which is
commit 746de82550 upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: I13648075fb2871b25977bc22ce6d11bd9e795506
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 774dd6f0f0 which is
commit d659bc68ed489022ea33342cfbda2911a81e7a0d upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: I6295c420bb6642fb9f04770a9f3baefa2d0aee72
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 8532fd078d which is
commit b44b9bc7cab2967c3d6a791b1cd542c89fc07f0e upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: I2ae4174ecb2214b5c1bc30b07970dd3468c1b43f
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 371e1a0e38 which is
commit 52b33d87b9 upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: Ic3741eb342637ace98373f24857a4d302cf7cfc7
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit a18682ccd2 which is
commit a430d99e349026d53e2557b7b22bd2ebd61fe12a upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: Ia71eb1867950bae93b6c426a596d584716137b29
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Steps on the way to 6.1.129
Resolves merge conflicts in:
kernel/sched/fair.c
Change-Id: I875e1c0846dd439a019d0d5b81f09cdac4a5c74e
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Catch the lts branch up with changes made in the normal one. Commits
include in here are:
* a624f97c9a Merge tag 'android14-6.1.128_r00' into android14-6.1
* 52a41f0bf1 ANDROID: usb: typec: tcpci: Combine the parameters of set_auto_vbus_discharge_threshold
* f84d5a5fad FROMGIT: usb: typec: tcpci: Prevent Sink disconnection before vPpsShutdown in SPR PPS
* a5f88b6529 UPSTREAM: f2fs: Optimize f2fs_truncate_data_blocks_range()
* 8171ecc314 BACKPORT: f2fs: add parameter @len to f2fs_invalidate_blocks()
* 2e7c1f7a45 UPSTREAM: f2fs: update_sit_entry_for_release() supports consecutive blocks.
* 80b35f89f0 BACKPORT: f2fs: introduce update_sit_entry_for_release/alloc()
* 600d7eac27 BACKPORT: f2fs: add parameter @len to f2fs_invalidate_internal_cache()
* 187a48cb98 UPSTREAM: f2fs: expand f2fs_invalidate_compress_page() to f2fs_invalidate_compress_pages_range()
* edcfc793f8 UPSTREAM: f2fs: fix to truncate meta inode pages forcely
* 3812bc69b2 BACKPORT: f2fs: introduce f2fs_invalidate_internal_cache() for cleanup
* ccc9157843 ANDROID: cma: Add restrict_cma_redirect boot parameter
* 34a86330cc FROMLIST: KVM: arm64: Fix alignment of kvm_hyp_memcache allocations
* c93dcf3b53 UPSTREAM: binder: log transaction code on failure
* 4e534b8a58 ANDROID: GKI: Galaxy android14-6.1 update symbol for alsa audio device
* 1ac09f5c05 ANDROID: GKI: Update symbol list for arg
* e5f309b277 ANDROID: dm-bow: Protect Ranges fetched and erased from the RB tree
* 09717ac61c ANDROID: Update the ABI symbol list
* 3031fa1817 ANDROID: Adding an Android vendor LMK event
* 7658169f5f BACKPORT: usb: xhci: Fix NULL pointer dereference on certain command aborts
* 4033df202b ANDROID: OPP: Fix incorrectly backported logic in _set_opp_level()
* 1cf6be7092 UPSTREAM: io_uring: fix waiters missing wake ups
* 2055772ead UPSTREAM: f2fs: avoid trying to get invalid block address
* 554eb9d61a ANDROID: KABI macros to release excess KABI fields for use with backports
* 773ad7ab13 ANDROID: GKI: Add new symbol list for arg
Change-Id: I71e368853a486e3893c0cc5b964b8fc3c390a4e9
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The change Ifdb1ba19f7147da286ea5e044e84dfb679050a94 ("FROMGIT: usb:
typec: tcpci: Prevent Sink disconnection before vPpsShutdown in SPR
PPS") breaks the KMI. Prevent the breakage by combining the parameters
"requested_vbus_voltage" and "pps_apdo_min_voltage" to a single u32
variable whose value is selected according to the values of parameter
"mode" and parameter "pps_active".
Bug: 388029777
Change-Id: I85872b9490561d248169bc8e008f3d907cc6c3c0
Signed-off-by: Kyle Tso <kyletso@google.com>
The Source can drop its output voltage to the minimum of the requested
PPS APDO voltage range when it is in Current Limit Mode. If this voltage
falls within the range of vPpsShutdown, the Source initiates a Hard
Reset and discharges Vbus. However, currently the Sink may disconnect
before the voltage reaches vPpsShutdown, leading to unexpected behavior.
Prevent premature disconnection by setting the Sink's disconnect
threshold to the minimum vPpsShutdown value. Additionally, consider the
voltage drop due to IR drop when calculating the appropriate threshold.
This ensures a robust and reliable interaction between the Source and
Sink during SPR PPS Current Limit Mode operation.
Fixes: 4288debeaa ("usb: typec: tcpci: Fix up sink disconnect thresholds for PD")
Cc: stable <stable@kernel.org>
Signed-off-by: Kyle Tso <kyletso@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20250114142435.2093857-1-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 388029777
(cherry picked from commit 4d27afbf256028a1f54363367f30efc8854433c3
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
usb-next)
Change-Id: Ifdb1ba19f7147da286ea5e044e84dfb679050a94
Signed-off-by: Kyle Tso <kyletso@google.com>
[ Upstream commit fcbd621567420b3a2f21f49bbc056de8b273c625 ]
kmemleak noticed that the iopf queue allocated deep down within
arm_smmu_init_structures() can be leaked by a subsequent error return
from arm_smmu_device_probe(). Furthermore, after arm_smmu_device_reset()
we will also leave the SMMU enabled with an empty Stream Table, silently
blocking all DMA. This proves rather annoying for debugging said probe
failure, so let's handle it a bit better by putting the SMMU back into
(more or less) the same state as if it hadn't probed at all.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/5137901958471cf67f2fad5c2229f8a8f1ae901a.1733406914.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4b5bc2ec9a239bce261ffeafdd63571134102323 ]
Now that the following fix:
d0ceea662d45 ("x86/mm: Add _PAGE_NOPTISHADOW bit to avoid updating userspace page tables")
stops kernel_ident_mapping_init() from scribbling over the end of a
4KiB PGD by assuming the following 4KiB will be a userspace PGD,
there's no good reason for the kexec PGD to be part of a single
8KiB allocation with the control_code_page.
( It's not clear that that was the reason for x86_64 kexec doing it that
way in the first place either; there were no comments to that effect and
it seems to have been the case even before PTI came along. It looks like
it was just a happy accident which prevented memory corruption on kexec. )
Either way, it definitely isn't needed now. Just allocate the PGD
separately on x86_64, like i386 already does.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Link: https://lore.kernel.org/r/20241205153343.3275139-6-dwmw2@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5fe71fda89745fc3cd95f70d06e9162b595c3702 ]
On a 32bit system the "keylen + sizeof(struct tipc_aead_key)" math could
have an integer wrapping issue. It doesn't matter because the "keylen"
is checked on the next line, but just to make life easier for static
analysis tools, let's re-order these conditions and avoid the integer
overflow.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 20a0c37e44063997391430c4ae09973e9cbc3911 ]
Qualcomm regulator supports two power supply modes: HPM and LPM.
Currently, the sdhci-msm.c driver does not set the load to adjust
the current for eMMC and SD. If the regulator dont't set correct
load in LPM state, it will lead to the inability to properly
initialize eMMC and SD.
Set the correct regulator current for eMMC and SD to ensure that the
device can work normally even when the regulator is in LPM.
Signed-off-by: Yuanjie Yang <quic_yuanjiey@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250114083514.258379-1-quic_yuanjiey@quicinc.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0b6f6593aa8c3a05f155c12fd0e7ad33a5149c31 ]
Currently, the driver is seriously broken with respect to the
hibernation (S4): after image restore the device is back into
IPC_MEM_EXEC_STAGE_BOOT (which AFAIK means bootloader stage) and needs
full re-launch of the rest of its firmware, but the driver restore
handler treats the device as merely sleeping and just sends it a
wake-up command.
This wake-up command times out but device nodes (/dev/wwan*) remain
accessible.
However attempting to use them causes the bootloader to crash and
enter IPC_MEM_EXEC_STAGE_CD_READY stage (which apparently means "a crash
dump is ready").
It seems that the device cannot be re-initialized from this crashed
stage without toggling some reset pin (on my test platform that's
apparently what the device _RST ACPI method does).
While it would theoretically be possible to rewrite the driver to tear
down the whole MUX / IPC layers on hibernation (so the bootloader does
not crash from improper access) and then re-launch the device on
restore this would require significant refactoring of the driver
(believe me, I've tried), since there are quite a few assumptions
hard-coded in the driver about the device never being partially
de-initialized (like channels other than devlink cannot be closed,
for example).
Probably this would also need some programming guide for this hardware.
Considering that the driver seems orphaned [1] and other people are
hitting this issue too [2] fix it by simply unbinding the PCI driver
before hibernation and re-binding it after restore, much like
USB_QUIRK_RESET_RESUME does for USB devices that exhibit a similar
problem.
Tested on XMM7360 in HP EliteBook 855 G7 both with s2idle (which uses
the existing suspend / resume handlers) and S4 (which uses the new code).
[1]: https://lore.kernel.org/all/c248f0b4-2114-4c61-905f-466a786bdebb@leemhuis.info/
[2]:
https://github.com/xmm7360/xmm7360-pci/issues/211#issuecomment-1804139413
Reviewed-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Link: https://patch.msgid.link/e60287ebdb0ab54c4075071b72568a40a75d0205.1736372610.git.mail@maciej.szmigiero.name
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5c0e00a391dd0099fe95991bb2f962848d851916 ]
The GHES driver overrides the panic= setting by force-rebooting the
system after a fatal hw error has been reported. The intent being that
such an error would be reported earlier.
However, this is not optimal when a hard-to-debug issue requires long
time to reproduce and when that happens, the box will get rebooted after
30 seconds and thus destroy the whole hw context of when the error
happened.
So rip out the default GHES panic timeout and honor the global one.
In the panic disabled (panic=0) case, the error will still be logged to
dmesg for later inspection and if panic after a hw error is really
required, then that can be controlled the usual way - use panic= on the
cmdline or set it in the kernel .config's CONFIG_PANIC_TIMEOUT.
Reported-by: Feng Tang <feng.tang@linux.alibaba.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Feng Tang <feng.tang@linux.alibaba.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Link: https://patch.msgid.link/20250113125224.GFZ4UMiNtWIJvgpveU@fat_crate.local
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit bfd74cd1fbc026f04446e67d6915c7e199c2bffd ]
When a 400KHz freq is used on this model of ELAN touchpad in Linux,
excessive smoothing (similar to when the touchpad's firmware detects
a noisy signal) is sometimes applied. As some devices' (e.g, Lenovo
V15 G4) ACPI tables specify a 400KHz frequency for this device and
some I2C busses (e.g, Designware I2C) default to a 400KHz freq,
force the speed to 100KHz as a workaround.
For future investigation: This problem may be related to the default
HCNT/LCNT values given by some busses' drivers, because they are not
specified in the aforementioned devices' ACPI tables, and because
the device works without issues on Windows at what is expected to be
a 400KHz frequency. The root cause of the issue is not known.
Signed-off-by: Randolph Ha <rha051117@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 80e96206a3ef348fbd658d98f2f43149c36df8bc ]
A caller of iwl_acpi_get_dsm_object must free the returned object.
iwl_acpi_get_dsm_integer returns immediately without freeing
it if the expected size is more than 8 bytes. Fix that.
Note that with the current code this will never happen, since the caller
of iwl_acpi_get_dsm_integer already checks that the expected size if
either 1 or 4 bytes, so it can't exceed 8 bytes.
While at it, print the DSM value instead of the return value, as this
was the intention in the first place.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241228223206.bf61eaab99f8.Ibdc5df02f885208c222456d42c889c43b7e3b2f7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e61e6c415ba9ff2b32bb6780ce1b17d1d76238f1 ]
The overflow_work is using system wq to do overflow checks and updates
for PHC device timecounter, which might be overhelmed by other tasks.
But there is dedicated kthread in PTP subsystem designed for such
things. This patch changes the work queue to proper align with PTP
subsystem and to avoid overloading system work queue.
The adjfine() function acts the same way as overflow check worker,
we can postpone ptp aux worker till the next overflow period after
adjfine() was called.
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
Acked-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20250107104812.380225-1-vadfed@meta.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1e89d21f8189d286f80b900e1b7cf57cb1f3037e ]
On N4100 / N4120 Gemini Lake SoCs the ISA bridge PCI device-id is 31e8
rather the 3197 found on e.g. the N4000 / N4020.
While at fix the existing GLK PCI-id table entry breaking the table
being sorted by device-id.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20241114193808.110132-1-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3df7546fc03b8f004eee0b9e3256369f7d096685 ]
syzbot is reporting too large allocation warning at tomoyo_write_control(),
for one can write a very very long line without new line character. To fix
this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,
for practically a valid line should be always shorter than 32KB where the
"too small to fail" memory-allocation rule applies.
One might try to write a valid line that is longer than 32KB, but such
request will likely fail with -ENOMEM. Therefore, I feel that separately
returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.
There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.
Reported-by: syzbot+7536f77535e5210a5c76@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7536f77535e5210a5c76
Reported-by: Leo Stone <leocstone@gmail.com>
Closes: https://lkml.kernel.org/r/20241216021459.178759-2-leocstone@gmail.com
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Sasha Levin <sashal@kernel.org>
