do_pages_move does not handle compat pointers for the page list.
correctly. Add in_compat_syscall check and appropriate get_user fetch
when iterating the page list.
It makes the syscall in compat mode (32-bit userspace, 64-bit kernel)
work the same way as the native 32-bit syscall again, restoring the
behavior before my broken commit 5b1b561ba7 ("mm: simplify
compat_sys_move_pages").
More specifically, my patch moved the parsing of the 'pages' array from
the main entry point into do_pages_stat(), which left the syscall
working correctly for the 'stat' operation (nodes = NULL), while the
'move' operation (nodes != NULL) is now missing the conversion and
interprets 'pages' as an array of 64-bit pointers instead of the
intended 32-bit userspace pointers.
It is possible that nobody noticed this bug because the few
applications that actually call move_pages are unlikely to run in
compat mode because of their large memory requirements, but this
clearly fixes a user-visible regression and should have been caught by
ltp.
Link: https://lkml.kernel.org/r/20231003144857.752952-1-gregory.price@memverge.com
Fixes: 5b1b561ba7 ("mm: simplify compat_sys_move_pages")
Signed-off-by: Gregory Price <gregory.price@memverge.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Co-developed-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
We used to determine the number of page table entries to set for a NAPOT
hugepage by using the pte value which actually fails when the pte to set
is a swap entry.
So take advantage of a recent fix for arm64 reported in [1] which
introduces the size of the mapping as an argument of set_huge_pte_at(): we
can then use this size to compute the number of page table entries to set
for a NAPOT region.
Link: https://lkml.kernel.org/r/20230928151846.8229-3-alexghiti@rivosinc.com
Fixes: 82a1a1f3bf ("riscv: mm: support Svnapot in hugetlb page")
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Reported-by: Ryan Roberts <ryan.roberts@arm.com>
Closes: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ [1]
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Qinglin Pan <panqinglin2020@iscas.ac.cn>
Cc: Conor Dooley <conor@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Patch series "Fix set_huge_pte_at()".
A recent report [1] from Ryan for arm64 revealed that we do not handle
swap entries when setting a hugepage backed by a NAPOT region (the contpte
riscv equivalent).
As explained in [1], the issue was discovered by a new test in kselftest
which uses poison entries, but the symptoms are different from arm64 though:
- the riscv kernel bugs because we do not handle VM_FAULT_HWPOISON*,
this is fixed by patch 1,
- after that, the test passes because the first pte_napot() fails (the
poison entry does not have the N bit set), and then we only set the
first page table entry covering the NAPOT hugepage, which is enough
for hugetlb_fault() to correctly raise a VM_FAULT_HWPOISON wherever we
write in this mapping since only this first page table entry is
checked
(see https://elixir.bootlin.com/linux/v6.6-rc3/source/mm/hugetlb.c#L6071).
But this seems fragile so patch 2 sets all page table entries of a
NAPOT mapping.
[1]: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/
This patch (of 2):
We used to panic when such faults were encountered but we should handle
those faults gracefully for userspace by sending a SIGBUS to the process,
like most architectures do.
Link: https://lkml.kernel.org/r/20230928151846.8229-1-alexghiti@rivosinc.com
Link: https://lkml.kernel.org/r/20230928151846.8229-2-alexghiti@rivosinc.com
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Conor Dooley <conor@kernel.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Qinglin Pan <panqinglin2020@iscas.ac.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When the calling function fails after the dup_anon_vma(), the
duplication of the anon_vma is not being undone. Add the necessary
unlink_anon_vma() call to the error paths that are missing them.
This issue showed up during inspection of the error path in vma_merge()
for an unrelated vma iterator issue.
Users may experience increased memory usage, which may be problematic as
the failure would likely be caused by a low memory situation.
Link: https://lkml.kernel.org/r/20230929183041.2835469-3-Liam.Howlett@oracle.com
Fixes: d4af56c5c7 ("mm: start tracking VMAs with maple tree")
Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Reviewed-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Jann Horn <jannh@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Calling vm_brk_flags() with flags set other than VM_EXEC will exit the
function without releasing the mmap_write_lock.
Just do the sanity check before the lock is acquired. This doesn't fix an
actual issue since no caller sets a flag other than VM_EXEC.
Link: https://lkml.kernel.org/r/20230929171937.work.697-kees@kernel.org
Fixes: 2e7ce7d354 ("mm/mmap: change do_brk_flags() to expand existing VMA and add do_brk_munmap()")
Signed-off-by: Sebastian Ott <sebott@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When guard page debug is enabled and set_page_guard returns success, we
miss to forward page to point to start of next split range and we will do
split unexpectedly in page range without target page. Move start page
update before set_page_guard to fix this.
As we split to wrong target page, then splited pages are not able to merge
back to original order when target page is put back and splited pages
except target page is not usable. To be specific:
Consider target page is the third page in buddy page with order 2.
| buddy-2 | Page | Target | Page |
After break down to target page, we will only set first page to Guard
because of bug.
| Guard | Page | Target | Page |
When we try put_page_back_buddy with target page, the buddy page of target
if neither guard nor buddy, Then it's not able to construct original page
with order 2
| Guard | Page | buddy-0 | Page |
All pages except target page is not in free list and is not usable.
Link: https://lkml.kernel.org/r/20230927094401.68205-1-shikemeng@huaweicloud.com
Fixes: 06be6ff3d2 ("mm,hwpoison: rework soft offline for free pages")
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
These pin definitions are helpful to have when working with the
driver in the future, so they are in a sense a bit like
documentation. They could be commented out as well, but why.
This should fix these build warnings:
drivers/pinctrl/realtek/pinctrl-rtd1315e.c:231:35: warning:
'rtd1315e_boot_sel_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1315e.c:231:35: warning:
'rtd1315e_reset_n_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1315e.c:231:35: warning:
'rtd1315e_scan_switch_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1315e.c:231:35: warning:
'rtd1315e_testmode_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1315e.c:231:35: warning:
'rtd1315e_wd_rset_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1319d.c:237:35: warning:
'rtd1319d_boot_sel_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1319d.c:237:35: warning:
'rtd1319d_reset_n_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1319d.c:237:35: warning:
'rtd1319d_scan_switch_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1319d.c:237:35: warning:
'rtd1319d_testmode_pins' defined but not used [-Wunused-const-variable=]
drivers/pinctrl/realtek/pinctrl-rtd1319d.c:237:35: warning:
'rtd1319d_wd_rset_pins' defined but not used [-Wunused-const-variable=]
Cc: Tzuyi Chang <tychang@realtek.com>
Link: https://lore.kernel.org/oe-kbuild-all/202309270313.mBEc9o1A-lkp@intel.com/
Link: https://lore.kernel.org/oe-kbuild-all/202309270448.7Aen3Sgx-lkp@intel.com/
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231006-fix-realtek-warnings-v1-1-09af253312ba@linaro.org
There are several issues in the probe function:
1) of_iomap() return NULL on error but the code checks for error
pointers.
2) pinctrl_register() is the reverse. It returns error pointers
but the code checks for NULL.
3) The error paths need to call iounmap(data->base) before returning
to avoid a resource leak.
Fixes: e99ce78030 ("pinctrl: realtek: Add common pinctrl driver for Realtek DHC RTD SoCs")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/590b337a-13ce-4391-a09d-d2b06fbc912d@moroto.mountain
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The state checker overwrites the old crtc state with the
current hardware state. While that does save a kmalloc() it seems
rather dubious as there might still be something that we need
in the old crtc state.
Stop doing that and just allocate a temporary state for the state
checker. Should the extra malloc during the commit phase turn out
too annoying we could of course preallocate one for each crtc, but
let's proceed with the straightforward approch for now.
And while at it let's mark the new crtc state as const to make
sure the state checker doesn't mess it up.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231004155607.7719-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
intel_psr_pre_plane_update() operates on a per-crtc level, whereas
intel_psr_post_plane_update() operates on the whole atomic commit,
for no real reason that I can see. Adjust intel_psr_post_plane_update()
to match the intel_psr_pre_plane_update() approach.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231004155607.7719-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The DSU PMU allows monitoring performance events in the DSU cluster,
which is done by configuring and reading back values from the DSU PMU
system registers. However, for write-access to be allowed by ELs lower
than EL3, the EL3 firmware needs to update the setting on the ACTLR3_EL3
register, as it is disallowed by default.
That configuration is not done on the firmware used by the MT8195 SoC,
as a consequence, booting a MT8195-based machine like
mt8195-cherry-tomato-r2 with CONFIG_ARM_DSU_PMU enabled hangs the kernel
just as it writes to the CLUSTERPMOVSCLR_EL1 register, since the
instruction faults to EL3, and BL31 apparently just re-runs the
instruction over and over.
Mark the DSU PMU node in the Devicetree with status "fail", as the
machine doesn't have a suitable firmware to make use of it from the
kernel, and allowing its driver to probe would hang the kernel.
Fixes: 37f2582883 ("arm64: dts: Add mediatek SoC mt8195 and evaluation board")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230720200753.322133-1-nfraprado@collabora.com
Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-5-dad7cd62a8ff@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
dtbs_check throws a warning at t-phy nodes:
Warning (unit_address_vs_reg): /t-phy@1a243000: node has a unit name, but no reg or ranges property
Warning (unit_address_vs_reg): /soc/t-phy@11c00000: node has a unit name, but no reg or ranges property
The ranges is empty thus removing the `@1a243000`, `@11c00000` from
the node name.
Fixes: 6029cae696 ("arm64: dts: mediatek: mt7622: harmonize node names and compatibles")
Fixes: 918aed7abd ("arm64: dts: mt7986: add pcie related device nodes")
Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230814093931.9298-2-eugen.hristev@collabora.com
Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-4-dad7cd62a8ff@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The dts file of the MediaTek MT8195 demo board has been updated to include
new reserved memory regions.
These reserved memory regions are:
- SCP
- VPU,
- Sound DMA
- APU.
These regions are defined with the "shared-dma-pool" compatible property.
In addition, the existing reserved memory regions have been reordered by
their addresses to improve readability and maintainability of the DTS
file.
Cc: stable@vger.kernel.org # 6.1, 6.4, 6.5
Fixes: e4a4175201 ("arm64: dts: mediatek: mt8195-demo: fix the memory size of node secmon")
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230905034511.11232-2-macpaul.lin@mediatek.com
Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-3-dad7cd62a8ff@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I am a top reviewer mainly for MediaTek SoC related patches in most
subsystems and I've also been upstreaming both improvements, fixes
and new drivers and devicetrees when required.
The MediaTek scene saw a generous increase in number of patches that
are sent to the lists every week, increasing the amount of required
efforts to maintain the MTK bits overall, and we will possibly see
even more of that.
For this reason, and also because of suggestions and encouragement
coming from the community, I'm stepping up to be a co-maintainer of
MediaTek SoCs support.
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20230929082009.71843-1-angelogioacchino.delregno@collabora.com
Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-1-dad7cd62a8ff@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fix spelling of "architecture" in the Kbuild file.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
commit c35559f94e ("x86/shstk: Introduce map_shadow_stack syscall")
recently added support for map_shadow_stack() but it is limited to x86
only for now. There is a possibility that other architectures (namely,
arm64 and RISC-V), that are implementing equivalent support for shadow
stacks, might need to add support for it.
Independent of that, reserving arch-specific syscall numbers in the
syscall tables of all architectures is good practice and would help
avoid future conflicts. map_shadow_stack() is marked as a conditional
syscall in sys_ni.c. Adding it to the syscall tables of other
architectures is harmless and would return ENOSYS when exercised.
Note, map_shadow_stack() was assigned #453 during the merge process
since #452 was taken by fchmodat2().
For Powerpc, map it to sys_ni_syscall() as is the norm for Powerpc
syscall tables.
For Alpha, map_shadow_stack() takes up #563 as Alpha still diverges from
the common syscall numbering system in the other architectures.
Link: https://lore.kernel.org/lkml/20230515212255.GA562920@debug.ba.rivosinc.com/
Link: https://lore.kernel.org/lkml/b402b80b-a7c6-4ef0-b977-c0f5f582b78a@sirena.org.uk/
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct cpuinfo_tree.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175159.work.357-kees@kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
The Energy Aware Scheduler (EAS) relies on the schedutil governor.
When moving to/from the schedutil governor, sched domains must be
rebuilt to allow re-evaluating the enablement conditions of EAS.
This is done through sched_cpufreq_governor_change().
Having a cpufreq governor assumes a cpufreq driver is running.
Inserting/removing a cpufreq driver should trigger a re-evaluation
of EAS enablement conditions, avoiding to see EAS enabled when
removing a running cpufreq driver.
Rebuild the sched domains in schedutil's sugov_init()/sugov_exit(),
allowing to check EAS's enablement condition whenever schedutil
governor is initialized/exited from.
Move relevant code up in schedutil.c to avoid a split and conditional
function declaration.
Rename sched_cpufreq_governor_change() to sugov_eas_rebuild_sd().
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The userspace governor uses the 'cpu' field of cpufreq_policy structure
to track if it is allowed to set the speed of the policy.
However, there is a window where the 'cpu' field is equal to the value
of nr_cpus_id when all affected CPUs of policy are offline, which is an
illegal value to get the per-CPU variable.
To avoid this issue, modify the governor to use a per-policy indicator
to track if the policy is managed.
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The userspace governor currently uses a big global mutex to avoid the
race condition on the governor_data field of cpufreq_policy structure.
This leads to a low concurrency if multiple userspace applications are
trying to set the speed of different policies at the same time.
Introduce a per-policy mutex to allow the updating of different policies
to be performed concurrently, improving overall concurrency.
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The governor currently checks if the input new down_threshold is less
than 100 before storing it, but the up_threshold field of dbs_data
structure is also limited to be less than 100, so this check is
unnecessary and remove it.
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The initialization code of the per-cpu sg_cpu struct is currently split
into two for-loop blocks. This can be simplified by merging the two
blocks into a single loop. This will make the code more maintainable.
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Main updates include:
1. Addition of support for Type 4 PCC subspace that enables platform
notification handling (Huisong Li).
2. Support for the shared interrupt amongst multiple PCC subspaces/
channels (Huisong Li).
3. Consolidation of PCC shared memory region command and status
bitfields definitions that were duplicated and scattered across
multiple PCC client drivers (Sudeep Holla).
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmUf3y8ACgkQAEG6vDF+
4phTng/+Jp8DG6bNQidDLndQeUyiB2Ip9iPN72ucBVla9ZxWg7cQ2ljvmgOBI0AY
V9DeBOXrkwln1TNaSxF5oyse8aUD6pU3e+V5QcTfUVFl9xUOVkgmlcV8RJOsHQyu
h42P/ZsTg/TmiXOP6XUDWxS5Gdr0quYGl5Jk8YWFCdfvmj/k2/b5F+dLRujjWaZY
EzaFWGoF8xavi96uqbzi0q9cAuqZtnhpPeP9ZzIhTYjDNMIyBRd7Paq7ESlq3omH
8W4zRkRaxPsNYmjAs2mnaOPQDy4gt1taJrRnQHwiebq2Gtqj6iNF1HT//hbYwL+d
dZjccM9J0bP0n7459dwJugOumRSByZgwh4UT+lHdKeJmWmoZpoTXjkBfRjdg2piv
DdE9ap2Wn+1xW7OF6lpeH75nFWo+/MRVufYU6mQ+7Zt1Ez0K9JTFm2VWo2fZqTx3
TG8LhjDX1SL12/e4kp+37z2RIpjkW5sf1m5uzTZzLwDwGUkKB1TZtU8MCK81erlA
c9bmU9BtPhnft4CaAipwhnwyDPUUXCxVUpL3E5uknlBUU+1B7JyuaEarfQFg6I1Y
JiZk11abrRQpva1myU16IYmuPiM1XJ9Mc5RCO0URv+tDoTEHpm707nbRn0jZgCNz
O6DcUdES0bA2bySJ1kWfQfdghHSiHphzl15I4L/J69eMRToEFpk=
=bZ1a
-----END PGP SIGNATURE-----
Merge tag 'acpi-pcc-updates-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux
Merge ACPI PCC changes for v6.7 from Sudeep Holla:
"ACPI: PCC: Mailbox and generic updates for v6.7
Main updates include:
1. Addition of support for Type 4 PCC subspace that enables platform
notification handling (Huisong Li).
2. Support for the shared interrupt amongst multiple PCC subspaces/
channels (Huisong Li).
3. Consolidation of PCC shared memory region command and status
bitfields definitions that were duplicated and scattered across
multiple PCC client drivers (Sudeep Holla)."
* tag 'acpi-pcc-updates-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
soc: kunpeng_hccs: Migrate to use generic PCC shmem related macros
hwmon: (xgene) Migrate to use generic PCC shmem related macros
i2c: xgene-slimpro: Migrate to use generic PCC shmem related macros
ACPI: PCC: Add PCC shared memory region command and status bitfields
mailbox: pcc: Support shared interrupt for multiple subspaces
mailbox: pcc: Add support for platform notification handling
The CONFIG_PCI_P2PDMA Kconfig help text contains a Cyrillic small "Dze"
(ѕ). When menuconfig renders it, it looks like "Enable ~U drivers" instead
of "Enables drivers".
Replace it by a plain "s" so the help text is displayed correctly by
menuconfig.
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> later posted the same
patch at
https://lore.kernel.org/r/20231006150209.87666-1-u.kleine-koenig@pengutronix.de
Link: https://lore.kernel.org/r/1658301723-111283-1-git-send-email-liusong@linux.alibaba.com
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Liu Song <liusong@linux.alibaba.com>
[bhelgaas: commit log, add Uwe's report]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
The correct name of this chip is MXC4005, not MX4005. This is confirmed
both by the manufacturer website and by the title of the original commit,
which added other MXCxxxx devices as well but only this one misses a "c" in
the compatible string.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Fixes: d9bf5d37fd ("dt-bindings:trivial-devices: Add memsic,mxc4005/mxc6255/mxc6655 entries")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20231004-mxc4005-device-tree-support-v1-1-e7c0faea72e4@bootlin.com
Signed-off-by: Rob Herring <robh@kernel.org>
The 'msi' child node schema is missing constraints on additional properties.
It turns out it is incomplete and properties for it are documented in the
parent node by mistake. Move the reference to msi-controller.yaml and
the custom properties to the 'msi' node. Adding 'unevaluatedProperties'
ensures all the properties in the 'msi' node are documented.
With the schema corrected, a minimal interrupt controller node is needed
to properly decode the interrupt properties since the example has
multiple interrupt parents.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Fixes: 905b986d09 ("dt-bindings: pci: Convert iProc PCIe to YAML")
Link: https://lore.kernel.org/r/20230926155613.33904-3-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Drop the unnecessary listing of properties already defined in
pci-bus.yaml. Unless there are additional constraints, it is not
necessary.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20230926155351.31117-2-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
The example's indentation is off. While fixing this, the 'bus' node
is unnecessary and can be dropped. It is also preferred to split up
unrelated examples to their own entries.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230926155351.31117-1-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Just as unevaluatedProperties or additionalProperties are required at
the top level of schemas, they should (and will) also be required for
child node schemas. That ensures only documented properties are
present for any node.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230925212803.1976803-1-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
A bus schema based on simple-pm-bus shouldn't define how many 'reg' entries
a child device has. That is a property of the device. Drop the 'reg' entry.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230925212639.1975002-1-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Extract duplicate code from these four functions
unix_redir_to_connected()
udp_redir_to_connected()
inet_unix_redir_to_connected()
unix_inet_redir_to_connected()
to generate a new helper pairs_redir_to_connected(). Create the
different socketpairs in these four functions, then pass the
socketpairs info to the new common helper to do the connections.
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Link: https://lore.kernel.org/r/54bb28dcf764e7d4227ab160883931d2173f4f3d.1696588133.git.geliang.tang@suse.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
We currently expect up to a three-digit number of tests and subtests, so:
#999/999: some_test/some_subtest: ...
Is the largest test/subtest we can see. If we happen to cross into
1000s, current logic will just truncate everything after 7th character.
This patch fixes this truncate and allows to go way higher (up to 31
characters in total). We still nicely align test numbers:
#60/66 core_reloc_btfgen/type_based___incompat:OK
#60/67 core_reloc_btfgen/type_based___fn_wrong_args:OK
#60/68 core_reloc_btfgen/type_id:OK
#60/69 core_reloc_btfgen/type_id___missing_targets:OK
#60/70 core_reloc_btfgen/enumval:OK
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/bpf/20231006175744.3136675-3-andrii@kernel.org
Add support for building selftests with -O2 level of optimization, which
allows more compiler warnings detection (like lots of potentially
uninitialized usage), but also is useful to have a faster-running test
for some CPU-intensive tests.
One can build optimized versions of libbpf and selftests by running:
$ make RELEASE=1
There is a measurable speed up of about 10 seconds for me locally,
though it's mostly capped by non-parallelized serial tests. User CPU
time goes down by total 40 seconds, from 1m10s to 0m28s.
Unoptimized build (-O0)
=======================
Summary: 430/3544 PASSED, 25 SKIPPED, 4 FAILED
real 1m59.937s
user 1m10.877s
sys 3m14.880s
Optimized build (-O2)
=====================
Summary: 425/3543 PASSED, 25 SKIPPED, 9 FAILED
real 1m50.540s
user 0m28.406s
sys 3m13.198s
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/bpf/20231006175744.3136675-2-andrii@kernel.org
Fix a bunch of potentially unitialized variable usage warnings that are
reported by GCC in -O2 mode. Also silence overzealous stringop-truncation
class of warnings.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/bpf/20231006175744.3136675-1-andrii@kernel.org
Currently, there exists a system-wide setting related to CPU security
mitigations, denoted as 'mitigations='. When set to 'mitigations=off', it
deactivates all optional CPU mitigations. Therefore, if we implement a
system-wide 'mitigations=off' setting, it should inherently bypass Spectre
v1 and Spectre v4 in the BPF subsystem.
Please note that there is also a more specific 'nospectre_v1' setting on
x86 and ppc architectures, though it is not currently exported. For the
time being, let's disregard more fine-grained options.
This idea emerged during our discussion about potential Spectre v1 attacks
with Luis [0].
[0] https://lore.kernel.org/bpf/b4fc15f7-b204-767e-ebb9-fdb4233961fb@iogearbox.net
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Song Liu <song@kernel.org>
Acked-by: KP Singh <kpsingh@kernel.org>
Cc: Luis Gerhorst <gerhorst@cs.fau.de>
Link: https://lore.kernel.org/bpf/20231005084123.1338-1-laoar.shao@gmail.com
In x86 virtualization environments, including TDX, RDTSC instruction is
handled without causing a VM exit, resulting in minimal overhead and
jitters. On the other hand, other clock sources (such as HPET, ACPI
timer, APIC, etc.) necessitate VM exits to implement, resulting in more
fluctuating measurements compared to TSC. Thus, those clock sources are
not effective for calibrating TSC.
As a foundation, the host TSC is guaranteed to be invariant on any
system which enumerates TDX support.
TDX guests and the TDX module build on that foundation by enforcing:
- Virtual TSC is monotonously incrementing for any single VCPU;
- Virtual TSC values are consistent among all the TD’s VCPUs at the
level supported by the CPU:
+ VMM is required to set the same TSC_ADJUST;
+ VMM must not modify from initial value of TSC_ADJUST before
SEAMCALL;
- The frequency is determined by TD configuration:
+ Virtual TSC frequency is specified by VMM on TDH.MNG.INIT;
+ Virtual TSC starts counting from 0 at TDH.MNG.INIT;
The result is that a reliable TSC is a TDX architectural guarantee.
Use the TSC as the only reliable clock source in TD guests, bypassing
unstable calibration.
This is similar to what the kernel already does in some VMWare and
HyperV environments.
[ dhansen: changelog tweaks ]
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: Erdem Aktas <erdemaktas@google.com>
Reviewed-by: Isaku Yamahata <isaku.yamahata@intel.com>
Acked-by: Kai Huang <kai.huang@intel.com>
Link: https://lore.kernel.org/all/20231006144549.2633-1-kirill.shutemov%40linux.intel.com
On i.MX8MQ the MIPI CSI block does have an associated power-domain, but
the CSI bridge does not.
Remove the power-domains requirement from the i.MX8MQ CSI bridge
to fix the following schema warning:
imx8mq-librem5-r4.dtb: csi@30a90000: 'power-domains' is a required property
from schema $id: http://devicetree.org/schemas/media/nxp,imx7-csi.yaml#
Fixes: de65538684 ("media: dt-bindings: media: imx7-csi: Document i.MX8M power-domains property")
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20231004201105.2323758-1-festevam@gmail.com
Signed-off-by: Rob Herring <robh@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEEgMe7l+5h9hnxdsnuWYigwDrT+vwFAmUgHWsUHGJoZWxnYWFz
QGdvb2dsZS5jb20ACgkQWYigwDrT+vxMJg//T5TAOGAChU8YoPoUMsVeRYNOqkG9
G+rWydRr/Mj7dWg0zdi5L7fi/krFx+BdSpaq4DnVu6YgGboLnlP+Z4/gqXeFfO+j
lPP5OG3uOOLkw7aktYCRFdSkryrzm02eQDfiT/boL9hqF1ioyoWHgk4E7AITYgkH
/ZHL/R6OllwuLfqI9MAFZ/9aKkTtezSqTGOMnOZSUu/OykP26hJhCmq4SlmZoVwV
lc6DdxCzACfgnX1dOiaia42PaDbU0niwtiQw56bksk1oebEULbr/OuKRRm5zjfTE
5aLXJbrM5W8KOnO6sTuDy2FDb/BlFi3dC+TF1FrAEqnnuY3nHDSpNSiAmu3JU4qA
pHMLRoVWcewoDlI4cqeTg2eh8n82pnfkl8UOtgi0KzmCnaZzoZzr3aYQ9etK7XcK
CGFmGaoQ9zXXH60VCiRqSTcr11PoVulIbn+Aa6s3uw5KQxvDArPLuMl1ljngCinR
U127D77u//BqjRVdB9mY69JCXyp9LCwBJ/tN20Jj1yeDfX43OgB0oSy7A7eYQwoZ
oydgSaSE0bRSEl6lRmmQsNhz3Qcwe/l+x+LNEpU2IBMkUD4SuW5L2zjZAmzHtM/6
9mUBLUh9JhxTk+2/7q0DL4UiMmx2AKkdt5vCNdDeFmKF+MYg7YYEfORRJYlSTDcO
Ay6aBBcoV4KXGnk=
=6O20
-----END PGP SIGNATURE-----
Merge tag 'pci-v6.6-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
Pull PCI fixes from Bjorn Helgaas:
- Fix a qcom register offset that broke IPQ8074 PCIe controller
enumeration (Sricharan Ramabadhran)
- Handle interrupt parsing failures when creating a device tree node to
avoid using uninitialized data (Lizhi Hou)
- Clean up if adding PCI device node fails when creating a device tree
node to avoid a memory leak (Lizhi Hou)
- If a link is down, mark all downstream devices as "disconnected" so
we don't wait for them on resume (Mika Westerberg)
* tag 'pci-v6.6-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci:
PCI/PM: Mark devices disconnected if upstream PCIe link is down on resume
PCI: of: Destroy changeset when adding PCI device node fails
PCI: of_property: Handle interrupt parsing failures
PCI: qcom: Fix IPQ8074 enumeration
Bug fixes, build warning fixes and DMI quirk additions for pdx86 for 6.6.
The following is an automated git shortlog grouped by driver:
hp-bioscfg:
- Fix reference leak
hp-wmi:
- Mark driver struct with __refdata to prevent section mismatch warning
platform/mellanox:
- tmfifo: fix kernel-doc warnings
platform/x86/intel/ifs:
- release cpus_read_lock()
think-lmi:
- Fix reference leak
touchscreen_dmi:
- Add info for the Positivo C4128B
- Add info for the BUSH Bush Windows tablet
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEEuvA7XScYQRpenhd+kuxHeUQDJ9wFAmUgKX0UHGhkZWdvZWRl
QHJlZGhhdC5jb20ACgkQkuxHeUQDJ9wF7gf+P4RmnOlZE/RyQ5nlhhWPyP9mY2ye
CsL1qZ5/lJNy99YaOo0LE4ZAptavXPjMhdgd68Dr7K8Gu+b74VweKmT3pP4ZtxzI
4RiDJD43SMGUMTNBaZtIje6o8l4YsjW4ckgcnA7Z5Eb0qNqcBNSQ0brlonVtSy0S
7s9ks5sG0KWVWLTa1h6S4ATRWaTUCwKpxiCeZ51eL5o0i8ggkSe0xOp117tMZ7P2
au0tO5uUh/rtnaJFu+zVOF1liXvFw5rBw/fr8tGhiWO26RLZ+qc9leOpmowEkcTM
StVuKowjuEMebZLsg7dRyTxW6g+ioEnnt89ofnw9JFmZA6TiRVFlPBGgkA==
=4Jkl
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v6.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Hans de Goede:
"Bug fixes, build warning fixes and DMI quirk additions"
* tag 'platform-drivers-x86-v6.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: hp-wmi:: Mark driver struct with __refdata to prevent section mismatch warning
platform/x86: touchscreen_dmi: Add info for the Positivo C4128B
platform/x86: touchscreen_dmi: Add info for the BUSH Bush Windows tablet
platform/mellanox: tmfifo: fix kernel-doc warnings
platform/x86/intel/ifs: release cpus_read_lock()
platform/x86: hp-bioscfg: Fix reference leak
platform/x86: think-lmi: Fix reference leak
Add void *context arrgument to the list of arguments of
acpi_dev_install_notify_handler() and modify it to pass that argument
as context to acpi_install_notify_handler() instead of its first
argument which is problematic in general (for example, if platform
drivers used it, they would rather get struct platform_device pointers
or pointers to their private data from the context arguments of their
notify handlers).
Make all of the current callers of acpi_dev_install_notify_handler()
take this change into account so as to avoid altering the general
functionality.
Co-developed-by: Michal Wilczynski <michal.wilczynski@intel.com>
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In some cases, ACPI drivers are implemented as a way to manage devices
enumerated with the help of the platform firmware through ACPI.
This might be confusing, since the preferred way to implement a driver
for a device that cannot be enumerated natively, is a platform
driver, as stated in the documentation.
Clarify relationships between ACPI device objects, platform devices and
ACPI Namespace entries.
Suggested-by: Elena Reshetova <elena.reshetova@intel.com>
Co-developed-by: Michal Wilczynski <michal.wilczynski@intel.com>
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
