aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-08-08net: stmmac: dwmac4: fix PCS duplex mode decodeRussell King (Oracle)2-3/+1
dwmac4 was decoding the duplex mode from the GMAC_PHYIF_CONTROL_STATUS register incorrectly, using GMAC_PHYIF_CTRLSTATUS_LNKMOD_MASK (value 1) rather than GMAC_PHYIF_CTRLSTATUS_LNKMOD (bit 16). Fix this. Fixes: 70523e639bf8c ("drivers: net: stmmac: reworking the PCS code.") Reviewed-by: Andrew Halaney <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Serge Semin <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-08x86/mm: Don't print out SRAT table informationLi RongQing1-4/+2
This per CPU log is becoming longer with more and more CPUs in system, which slows down the boot process due to the serializing nature of printk(). The value of this information is dubious and it can be retrieved by lscpu from user space if required.. Downgrade the printk() to pr_debug() so it is still accessible for debug purposes. [ tglx: Massaged changelog ] Signed-off-by: Li RongQing <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-08pinctrl: samsung: Add support for pull-up and pull-downVishnu Reddy4-0/+126
Gpiolib framework has the implementation of setting up the PUD configuration for GPIO pins but there is no driver support. Add support to handle the PUD configuration request from the userspace in samsung pinctrl driver. Signed-off-by: Vishnu Reddy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-08-08genirq: Remove irq_chip_regs:: PolarityJiri Slaby (SUSE)1-2/+0
The polarity member of struct irq_chip_regs is unused. Remove it along with its kernel-doc. Found by https://github.com/jirislaby/clang-struct. Signed-off-by: Jiri Slaby (SUSE) <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-08genirq: Remove unused irq_chip_generic:: {type,polarity}_cacheJiri Slaby (SUSE)1-4/+0
The type_cache and polarity_cache members of struct irq_chip_generic are unused. Remove them both along with their kernel-doc. Found by https://github.com/jirislaby/clang-struct. Signed-off-by: Jiri Slaby (SUSE) <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-08genirq/irq_sim: Remove unused irq_sim_work_ctx:: Irq_baseJiri Slaby (SUSE)1-1/+0
Since commit 337cbeb2c13e ("genirq/irq_sim: Simplify the API"), irq_sim_work_ctx::irq_base is unused. Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by: Jiri Slaby (SUSE) <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-08irqchip/mbigen: Simplify code logic with for_each_child_of_node_scoped()Zhang Zekun1-17/+7
for_each_child_of_node_scoped() handles the device_node automaticlly, so switching over to it removes the device node cleanups and allows to return directly from the loop. Signed-off-by: Zhang Zekun <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-08irqchip/armada-370-xp: Use mpic_is_ipi_available() in mpic_of_init()Marek Behún1-1/+1
mpic_of_init() contains the last case where the open coded IPI support condition needs to be replaced with mpic_is_ipi_available() to keep the code consistent. Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08irqchip/armada-370-xp: Allow mapping only per-CPU interruptsMarek Behún1-6/+13
On platforms where MPIC is not the top-level interrupt controller the driver currently only supports handling of the per-CPU interrupts (the first 29 interrupts). This is obvious from the code of mpic_handle_cascade_irq(), which reads only one cause register. Bound the number of available interrupts in the interrupt domain to 29 for these platforms. The corresponding device-trees refer only to per-CPU interrupts via MPIC, the other interrupts are referred to via GIC. Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08irqchip/armada-370-xp: Iterate only valid bits of the per-CPU interrupt ↵Marek Behún1-1/+1
cause register Use MPIC_PER_CPU_IRQS_NR (29) bound instead of BITS_PER_LONG (32) when iterating the bits of the per-CPU interrupt cause register, since there are only 29 per-CPU interrupts. The top 3 bits are always zero anyway. Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08irqchip/armada-370-xp: Fix reenabling last per-CPU interruptMarek Behún1-3/+3
The number of per-CPU interrupts is 29 (0 to 28). This is described by the constant MPIC_MAX_PER_CPU_IRQS, set to 28 (the maximum per-CPU interrupt). Commit 0fa4ce746d1d ("irqchip/armada-370-xp: Re-enable per-CPU interrupts at resume time") used the constant incorrectly in the for-loop, it used the operator < instead of <=, causing it to iterate only the first 28 interrupts (0 to 27), ignoring the last, 28th, per-CPU interrupt. To avoid this kind of confusions, fix this issue by renaming the constant to MPIC_PER_CPU_IRQS_NR and set it to 29, the number of per-CPU IRQs. Update its use in mpic_is_percpu_irq() accordingly. Fixes: 0fa4ce746d1d ("irqchip/armada-370-xp: Re-enable per-CPU interrupts at resume time") Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: <[email protected]> # The 29th interrupt is not used in any device-tree
2024-08-08irqchip/armada-370-xp: Dynamically allocate the driver private structureMarek Behún1-5/+11
Dynamically allocate the driver private structure. This concludes the conversion of this driver to modern style. Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08irqchip/armada-370-xp: Pass around the driver private structureMarek Behún1-45/+70
In continuation of converting the driver to modern style, drop the global pointer to the driver private structure and instead pass it around the functions and callbacks, wherever possible. (There are 3 cases where it is not possible: mpic_cascaded_starting_cpu() and the syscore operations mpic_suspend() and mpic_resume()). Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08irqchip/armada-370-xp: Put MSI doorbell limits into the mpic structureMarek Behún1-22/+22
Put the MSI doorbell limits msi_doorbell_start, msi_doorbell_size and msi_doorbell_mask into the driver private structure and get rid of the corresponding functions. Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08irqchip/armada-370-xp: Put static variables into driver private structureMarek Behún1-101/+122
In preparation for converting the driver to modern style put all the interrupt controller private static variables into driver private structure. Access to these variables changes as: main_int_base mpic->base per_cpu_int_base mpic->per_cpu mpic_domain mpic->domain parent_irq mpic->parent_irq ... Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08irqchip/armada-370-xp: Put __init attribute after return type in mpic_ipi_init()Marek Behún1-1/+1
For consistency with the rest of the driver, put the __init attribute after the return type of the mpic_ipi_init() function. Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08irqchip/armada-370-xp: Add the __init attribute to mpic_msi_init()Marek Behún1-1/+1
Add the __init attribute to the mpic_msi_init() function. It is only called from the device initializer, and so can be dropped after boot is complete. Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08irqchip/armada-370-xp: Drop msi_doorbell_end()Marek Behún1-7/+0
Drop the msi_doorbell_end() function and related constants, it is not used anymore. Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08irqchip/armada-370-xp: Drop IPI_DOORBELL_START and rename IPI_DOORBELL_ENDMarek Behún1-7/+6
Drop IPI_DOORBELL_START since it is not used and rename IPI_DOORBELL_END to IPI_DOORBELL_NR. Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2024-08-08x86/mtrr: Check if fixed MTRRs exist before saving themAndi Kleen1-1/+1
MTRRs have an obsolete fixed variant for fine grained caching control of the 640K-1MB region that uses separate MSRs. This fixed variant has a separate capability bit in the MTRR capability MSR. So far all x86 CPUs which support MTRR have this separate bit set, so it went unnoticed that mtrr_save_state() does not check the capability bit before accessing the fixed MTRR MSRs. Though on a CPU that does not support the fixed MTRR capability this results in a #GP. The #GP itself is harmless because the RDMSR fault is handled gracefully, but results in a WARN_ON(). Add the missing capability check to prevent this. Fixes: 2b1f6278d77c ("[PATCH] x86: Save the MTRRs of the BSP before booting an AP") Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/[email protected]
2024-08-08drm/i915: remove __i915_printk()Jani Nikula2-48/+6
With the previous cleanups, the last remaining user of __i915_printk() is i915_probe_error(). Switch that to use drm_dbg() and drm_err() instead, dropping the request to report bugs in the few remaining specific cases. It's not common for drivers to log bug filing requests to begin with, but these cases are in init, which is most likely to be tested in CI and least likely to be hit by end users anyway. Acked-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/be9baeab281f75999e96cc7ad1c06c6680494bc1.1722951405.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-08-08Merge tag 'mm-hotfixes-stable-2024-08-07-18-32' of ↵Linus Torvalds8-22/+71
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "Nine hotfixes. Five are cc:stable, the others either pertain to post-6.10 material or aren't considered necessary for earlier kernels. Five are MM and four are non-MM. No identifiable theme here - please see the individual changelogs" * tag 'mm-hotfixes-stable-2024-08-07-18-32' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: padata: Fix possible divide-by-0 panic in padata_mt_helper() mailmap: update entry for David Heidelberg memcg: protect concurrent access to mem_cgroup_idr mm: shmem: fix incorrect aligned index when checking conflicts mm: shmem: avoid allocating huge pages larger than MAX_PAGECACHE_ORDER for shmem mm: list_lru: fix UAF for memory cgroup kcov: properly check for softirq context MAINTAINERS: Update LTP members and web selftests: mm: add s390 to ARCH check
2024-08-08drm/i915: remove i915_report_error()Jani Nikula2-7/+4
i915_report_error() presently acts as a wrapper for __i915_printk(). In practice, it would be better to use drm level error reporting wherever possible, so replace all uses of i915_report_error() with the equivalent drm_err() call. These cases are not worth having a dedicated wrapper to also print bug reporting info. Replacing the calls leaves i915_report_error() with no users, so remove it. Reviewed-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/19eab020c57c0fa45acacf4e4a8077e57cd4d561.1722951405.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-08-08drm/i915: remove a few __i915_printk() usesJani Nikula1-5/+5
__i915_printk() does nothing special for notice/info levels. Just use the regular drm_notice() and drm_info() calls. Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/82857a0c04d3c11ca6758f05c13a3cec4f1a2f01.1722951405.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-08-08perf test pmu: Set uninitialized PMU alias to nullVeronika Molnarova1-1/+3
Commit 3e0bf9fde2984469 ("perf pmu: Restore full PMU name wildcard support") adds a test case "PMU cmdline match" that covers PMU name wildcard support provided by function perf_pmu__match(). The test works with a wide range of supported combinations of PMU name matching but omits the case that if the perf_pmu__match() cannot match the PMU name to the wildcard, it tries to match its alias. However, this variable is not set up, causing the test case to fail when run with subprocesses or to segfault if run as a single process. ./perf test -vv 9 9: Sysfs PMU tests : 9.1: Parsing with PMU format directory : Ok 9.2: Parsing with PMU event : Ok 9.3: PMU event names : Ok 9.4: PMU name combining : Ok 9.5: PMU name comparison : Ok 9.6: PMU cmdline match : FAILED! ./perf test -F 9 9.1: Parsing with PMU format directory : Ok 9.2: Parsing with PMU event : Ok 9.3: PMU event names : Ok 9.4: PMU name combining : Ok 9.5: PMU name comparison : Ok Segmentation fault (core dumped) Initialize the PMU alias to null for all tests of perf_pmu__match() as this functionality is not being tested and the alias matching works exactly the same as the matching of the PMU name. ./perf test -F 9 9.1: Parsing with PMU format directory : Ok 9.2: Parsing with PMU event : Ok 9.3: PMU event names : Ok 9.4: PMU name combining : Ok 9.5: PMU name comparison : Ok 9.6: PMU cmdline match : Ok Fixes: 3e0bf9fde2984469 ("perf pmu: Restore full PMU name wildcard support") Signed-off-by: Veronika Molnarova <[email protected]> Cc: James Clark <[email protected]> Cc: Michael Petlan <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Radostin Stoyanov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-08-08media: cec: cec-adap.c: improve CEC_MSG_FL_REPLY_VENDOR_ID checkHans Verkuil1-5/+6
The new CEC_MSG_FL_REPLY_VENDOR_ID flag only makes sense in combination with CEC_MSG_VENDOR_COMMAND_WITH_ID. So rather than reporting an error if that flag is set with another command, just clear the flag instead. Only keep the message length check, since otherwise the flag would not make sense. Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2024-08-08media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flagsHans Verkuil1-1/+5
The cec_msg_set_reply_to() helper function never zeroed the struct cec_msg flags field, this can cause unexpected behavior if flags was uninitialized to begin with. Signed-off-by: Hans Verkuil <[email protected]> Fixes: 0dbacebede1e ("[media] cec: move the CEC framework out of staging and to media") Cc: <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2024-08-08Documentation: dontdiff: remove 'utf8data.h'ganjie1-1/+1
Commit 2b3d04787012 ("unicode: Add utf8-data module") changed the database file from 'utf8data.h' to 'utf8data.c' to build separate module, but it seems forgot to update Documentation/dontdiff. Remove 'utf8data.h' and add 'utf8data.c'. Signed-off-by: ganjie <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-08perf tests ftrace: Add pattern check for time, countArnaldo Carvalho de Melo1-0/+5
In 'perf ftrace profile sleep 0.1' we know that we'll have an specific kernel function that will take a bit more than 0.1 seconds and will take place just one time, so we can add a check for that so that we validate more than just the presence of some functions in the profile. Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Steven Rostedt (VMware) <[email protected]> Link: https://lore.kernel.org/lkml/ZrTBo7KACZeuCyLj@x1 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-08-08perf test: Add a new shell test for perf ftraceNamhyung Kim1-0/+84
$ sudo ./perf test ftrace -vv 86: perf ftrace tests: --- start --- test child forked, pid 1772223 perf ftrace list test syscalls for sleep: __x64_sys_nanosleep __ia32_sys_nanosleep __x64_sys_clock_nanosleep __ia32_sys_clock_nanosleep perf ftrace list test [Success] perf ftrace trace test # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 0) | __x64_sys_clock_nanosleep() { 0) | common_nsleep() { 0) | hrtimer_nanosleep() { 0) | do_nanosleep() { perf ftrace trace test [Success] perf ftrace latency test target function: __x64_sys_clock_nanosleep # DURATION | COUNT | GRAPH | 32 - 64 ms | 1 | ############################################## | perf ftrace latency test [Success] perf ftrace profile test # Total (us) Avg (us) Max (us) Count Function 100136.400 100136.400 100136.400 1 __x64_sys_clock_nanosleep 100135.200 100135.200 100135.200 1 common_nsleep 100134.700 100134.700 100134.700 1 hrtimer_nanosleep 100133.700 100133.700 100133.700 1 do_nanosleep 100130.600 100130.600 100130.600 1 schedule 166.868 55.623 80.299 3 scheduler_tick 5.926 5.926 5.926 1 native_smp_send_reschedule 301.941 301.941 301.941 1 __x64_sys_execve 295.786 295.786 295.786 1 do_execveat_common.isra.0 71.397 35.699 46.403 2 bprm_execve 2.519 1.260 1.547 2 sched_mm_cid_before_execve 1.098 0.549 0.686 2 sched_mm_cid_after_execve perf ftrace profile test [Success] ---- end(0) ---- 86: perf ftrace tests : Ok Signed-off-by: Namhyung Kim <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Steven Rostedt (VMware) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-08-08perf annotate-data: Show typedef names properlyNamhyung Kim3-10/+33
The die_get_typename() would resolve typedef and get to the original type. But sometimes the original type is a struct without name and it makes the output confusing and hard to read. This is a diff of perf report -s type before and after the change. New types such as atomic{,64}_t and sigset_t appeared and the portion of unnamed struct was reduced. Also u32, u64 and size_t were splitted from the base types. --- b 2024-08-01 17:02:34.307809952 -0700 +++ a 2024-08-07 14:17:05.245853999 -0700 - 2.40% long unsigned int + 2.26% long unsigned int - 1.56% unsigned int + 1.27% unsigned int - 0.98% struct - 0.79% long long unsigned int + 0.58% long long unsigned int + 0.36% struct + 0.27% atomic64_t + 0.22% u32 + 0.21% u64 + 0.19% atomic_t + 0.13% size_t - 0.08% struct seqcount_spinlock + 0.08% seqcount_spinlock_t + 0.08% sigset_t + 0.08% __poll_t Let's use the typedef name directly and the resolved to get the size of the type. Committer testing: root@x1:~# diff -u before after | head -30 --- before 2024-08-08 09:35:13.917325041 -0300 +++ after 2024-08-08 09:37:35.312257905 -0300 @@ -10,25 +10,27 @@ # ........ ......... # 79.40% (unknown) - 2.28% union 1.96% (stack operation) - 1.24% struct + 1.87% pthread_mutex_t 0.99% u32[] - 0.92% unsigned int 0.77% struct task_struct + 0.75% U32 0.75% struct pcpu_hot 0.63% struct qspinlock + 0.61% atomic_t 0.59% struct list_head - 0.58% int 0.53% struct cfs_rq 0.51% BYTE* - 0.48% unsigned char + 0.48% BYTE 0.48% long unsigned int 0.46% struct rq 0.41% struct worker 0.41% struct memcg_vmstats_percpu + 0.41% pthread_cond_t 0.37% _Bool + 0.36% int root@x1:~# Signed-off-by: Namhyung Kim <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-08-08perf annotate: Cache debuginfo for data type profilingNamhyung Kim5-14/+44
In find_data_type(), it creates and deletes a debug info whenver it tries to find data type for a sample. This is inefficient and it most likely accesses the same binary again and again. Let's add a single entry cache the debug info structure for the last DSO. Depending on sample data, it usually gives me 2~3x (and sometimes more) speed ups. Note that this will introduce a little difference in the output due to the order of checking stack operations. It used to check the stack ops before checking the availability of debug info but I moved it after the symbol check. So it'll report stack operations in DSOs without debug info as unknown. But I think it's ok and better to have the checking near the caching logic. Committer testing: root@x1:~# perf mem record -a sleep 5s root@x1:~# perf evlist cpu_atom/mem-loads,ldlat=30/P cpu_atom/mem-stores/P dummy:u root@x1:~# diff -u before after --- before 2024-08-08 09:33:53.880780784 -0300 +++ after 2024-08-08 09:35:13.917325041 -0300 @@ -81,8 +81,8 @@ # Overhead Data Type # ........ ......... # - 55.43% (unknown) - 11.61% (stack operation) + 55.56% (unknown) + 11.48% (stack operation) 4.93% struct pcpu_hot 3.26% unsigned int 2.48% struct Signed-off-by: Namhyung Kim <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-08-08perf hist: Fix reference counting of branch_infoIan Rogers1-4/+14
iter_finish_branch_entry() doesn't put the branch_info from/to map elements creating memory leaks. This can be seen with: ``` $ perf record -e cycles -b perf test -w noploop $ perf report -D ... Direct leak of 984344 byte(s) in 123043 object(s) allocated from: #0 0x7fb2654f3bd7 in malloc libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x564d3400d10b in map__get util/map.h:186 #2 0x564d3400d10b in ip__resolve_ams util/machine.c:1981 #3 0x564d34014d81 in sample__resolve_bstack util/machine.c:2151 #4 0x564d34094790 in iter_prepare_branch_entry util/hist.c:898 #5 0x564d34098fa4 in hist_entry_iter__add util/hist.c:1238 #6 0x564d33d1f0c7 in process_sample_event tools/perf/builtin-report.c:334 #7 0x564d34031eb7 in perf_session__deliver_event util/session.c:1655 #8 0x564d3403ba52 in do_flush util/ordered-events.c:245 #9 0x564d3403ba52 in __ordered_events__flush util/ordered-events.c:324 #10 0x564d3402d32e in perf_session__process_user_event util/session.c:1708 #11 0x564d34032480 in perf_session__process_event util/session.c:1877 #12 0x564d340336ad in reader__read_event util/session.c:2399 #13 0x564d34033fdc in reader__process_events util/session.c:2448 #14 0x564d34033fdc in __perf_session__process_events util/session.c:2495 #15 0x564d34033fdc in perf_session__process_events util/session.c:2661 #16 0x564d33d27113 in __cmd_report tools/perf/builtin-report.c:1065 #17 0x564d33d27113 in cmd_report tools/perf/builtin-report.c:1805 #18 0x564d33e0ccb7 in run_builtin tools/perf/perf.c:350 #19 0x564d33e0d45e in handle_internal_command tools/perf/perf.c:403 #20 0x564d33cdd827 in run_argv tools/perf/perf.c:447 #21 0x564d33cdd827 in main tools/perf/perf.c:561 ... ``` Clearing up the map_symbols properly creates maps reference count issues so resolve those. Resolving this issue doesn't improve peak heap consumption for the test above. Committer testing: $ sudo dnf install libasan $ make -k CORESIGHT=1 EXTRA_CFLAGS="-fsanitize=address" CC=clang O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin Reviewed-by: Kan Liang <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sun Haiyong <[email protected]> Cc: Yanteng Si <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-08-08platform/x86: ideapad-laptop: add a mutex to synchronize VPC commandsGergo Koteles1-17/+47
Calling VPC commands consists of several VPCW and VPCR ACPI calls. These calls and their results can get mixed up if they are called simultaneously from different threads, like acpi notify handler, sysfs, debugfs, notification chain. The commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") made the race issues much worse than before it but some races were possible even before that commit. Add a mutex to synchronize VPC commands. Fixes: e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") Fixes: e82882cdd241 ("platform/x86: Add driver for Yoga Tablet Mode switch") Signed-off-by: Gergo Koteles <[email protected]> Link: https://lore.kernel.org/r/f26782fa1194ad11ed5d9ba121a804e59b58b026.1721898747.git.soyer@irl.hu Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
2024-08-08platform/x86: ideapad-laptop: move ymc_trigger_ec from lenovo-ymcGergo Koteles4-58/+56
Some models need to trigger the EC after each YMC event for the yoga mode control to work properly. EC triggering consist of a VPC call from the lenovo-ymc module. Except for this, all VPC calls are in the ideapad-laptop module. Since ideapad-laptop has a notification chain, a new YMC_EVENT action can be added and triggered from the lenovo-ymc module. Then the ideapad-laptop can trigger the EC. If the triggering is in the ideapad-laptop module, then the ec_trigger module parameter should be there as well. Move the ymc_trigger_ec functionality and the ec_trigger module parameter to the ideapad-laptop module. Signed-off-by: Gergo Koteles <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/d980ab3ac32b5e554f456b0ff17279bfdbe2a203.1721898747.git.soyer@irl.hu Signed-off-by: Ilpo Järvinen <[email protected]>
2024-08-08platform/x86: ideapad-laptop: introduce a generic notification chainGergo Koteles2-0/+42
There are several cases where a notification chain can simplify Lenovo WMI drivers. Add a generic notification chain into ideapad-laptop. Signed-off-by: Gergo Koteles <[email protected]> Link: https://lore.kernel.org/r/c5a43efae8a32bd034c3d19c0a686941347575a7.1721898747.git.soyer@irl.hu Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
2024-08-08platform/x86/amd/pmf: Fix to Update HPD Data When ALS is DisabledShyam Sundar S K1-21/+11
If the Ambient Light Sensor (ALS) is disabled, the current code in the PMF driver does not query for Human Presence Detection (HPD) data in amd_pmf_get_sensor_info(). As a result, stale HPD data is used by PMF-TA to evaluate policy conditions, leading to unexpected behavior in the policy output actions. To resolve this issue, modify the PMF driver to query HPD data independently of ALS. Since user_present is a boolean, modify the current code to return true if the user is present and false if the user is away or if the sensor is not detected, and report this status to the PMF TA firmware accordingly. With this change, amd_pmf_get_sensor_info() now returns void instead of int. Fixes: cedecdba60f4 ("platform/x86/amd/pmf: Get ambient light information from AMD SFH driver") Co-developed-by: Patil Rajesh Reddy <[email protected]> Signed-off-by: Patil Rajesh Reddy <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]>
2024-08-08drm/i915: Replace double blank with single blank after commaAndi Shyti8-11/+11
Do not use double blanks, ", " in function parameters where it's not required by any alignment purpose. Replase it with a single blank, ", ". Signed-off-by: Andi Shyti <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-08drm/i915: Replace double blank with single blank after comma in gem/ and gt/Andi Shyti4-4/+4
Do not use double blanks, ", " in function parameters where it's not required by any alignment purpose. Replase it with a single blank, ", ". Signed-off-by: Andi Shyti <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-08perf: Optimize __pmu_ctx_sched_out()Peter Zijlstra1-1/+1
There is is no point in doing the perf_pmu_disable() dance just to do nothing. This happens for ctx_sched_out(.type = EVENT_TIME) for instance. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kan Liang <[email protected]> Reviewed-by: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-08perf: Add context time freezePeter Zijlstra1-42/+86
Many of the the context reschedule users are of the form: ctx_sched_out(.type = EVENT_TIME); ... modify context ctx_resched(); With the idea that the whole reschedule happens with a single time-stamp, rather than with each ctx_sched_out() advancing time and ctx_sched_in() re-starting time, creating a non-atomic experience. However, Kan noticed that since this completely stops time, it actually looses a bit of time between the stop and start. Worse, now that we can do partial (per PMU) reschedules, the PMUs that are not scheduled out still observe the time glitch. Replace this with: ctx_time_freeze(); ... modify context ctx_resched(); With the assumption that this happens in a perf_ctx_lock() / perf_ctx_unlock() pair. The new ctx_time_freeze() will update time and sets EVENT_FROZEN, and ensures EVENT_TIME and EVENT_FROZEN remain set, this avoids perf_event_time_now() from observing a time wobble from not seeing EVENT_TIME for a little while. Additionally, this avoids loosing time between ctx_sched_out(EVENT_TIME) and ctx_sched_in(), which would re-set the timestamp. Reported-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kan Liang <[email protected]> Reviewed-by: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-08perf: Fix event_function_call() lockingPeter Zijlstra1-4/+5
All the event_function/@func call context already uses perf_ctx_lock() except for the !ctx->is_active case. Make it all consistent. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kan Liang <[email protected]> Reviewed-by: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-08perf: Extract a few helpersPeter Zijlstra1-17/+22
The context time update code is repeated verbatim a few times. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kan Liang <[email protected]> Reviewed-by: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-08perf: Optimize context reschedule for single PMU casesPeter Zijlstra1-76/+88
Currently re-scheduling a context will reschedule all active PMUs for that context, even if it is known only a single event is added. Namhyung reported that changing this to only reschedule the affected PMU when possible provides significant performance gains under certain conditions. Therefore, allow partial context reschedules for a specific PMU, that of the event modified. While the patch looks somewhat noisy, it mostly just propagates a new @pmu argument through the callchain and modifies the epc loop to only pick the 'epc->pmu == @pmu' case. Reported-by: Namhyung Kim <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kan Liang <[email protected]> Reviewed-by: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-08soc: fsl: qbman: remove unused struct 'cgr_comp'Dr. David Alan Gilbert1-5/+0
'cgr_comp' has been unused since commit 96f413f47677 ("soc/fsl/qbman: fix issue in qman_delete_cgr_safe()"). Remove it. Signed-off-by: Dr. David Alan Gilbert <[email protected]> Reviewed-by: Sean Anderson <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2024-08-08dt-bindings: memory-controllers: fsl,imx-weim: Fix "fsl,weim-cs-timing" schemaRob Herring (Arm)1-14/+11
The "fsl,weim-cs-timing" property is an array, but the constraints in the if/then schema are for a matrix. That worked fine when all properties were decoded into a matrix, but now dtschema decodes properties into scalars and arrays based on their type. Signed-off-by: Rob Herring (Arm) <[email protected]> Acked-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-08-08drm/i915/gem: Improve pfn calculation readability in vm_fault_gtt()Andi Shyti1-6/+14
By moving the pfn calculation to the set_address_limits() function we improve code readability. This way, set_address_limits() is responsible for calculating all memory mapping paramenters: "start", "end" and "pfn". This suggestion from Jonathan was made during the review of commit 8bdd9ef7e9b1 ("drm/i915/gem: Fix Virtual Memory mapping boundaries calculation"), which I liked, but it got lost on the way. Suggested-by: Jonathan Cavitt <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Reviewed-by: Krzysztof Niemiec <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-08clk: samsung: exynos7885: Add missing MUX clocks from PLLs in CMU_TOPDavid Virag1-6/+16
In Exynos7885 (and seemingly all modern Exynos SoCs) all PLLs have a MUX attached to them controlled by bit 4 in the PLL's CON0 register. These MUXes can select between OSCCLK or the PLL's output, essentially making the PLL bypassable. These weren't modeled in the driver because the vendor provided drivers didn't model it properly, instead setting them when updating the PMS values. Not having them modeled didn't cause any problems in this case, since these MUXes were set to the PLL's output by default, but this is not the case everywhere in this SoC. Signed-off-by: David Virag <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-08-08clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fixDavid Virag1-1/+1
Update CLKS_NR_FSYS to the proper value after a fix in DT bindings. This should always be the last clock in a CMU + 1. Fixes: cd268e309c29 ("dt-bindings: clock: Add bindings for Exynos7885 CMU_FSYS") Cc: [email protected] Signed-off-by: David Virag <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-08-08Merge branch 'for-v6.12/clk-dt-bindings' into next/clkKrzysztof Kozlowski1-11/+21
Powered by cgit, Gruvboxed by Blaster4385.