summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-06-16perf/arm-cmn: Add sysfs identifierRobin Murphy
Expose a sysfs identifier encapsulating the CMN part number and revision so that jevents can narrow down a fundamental set of possible events for calculating metrics. Configuration-dependent aspects - such as whether a given node type is present, and/or a given node ID is valid - are still not covered, and in general it's hard to see how userspace could handle them, so we won't be removing any data or validation logic from the driver any time soon, but at least it's a step in a useful direction. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-and-tested-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Tested-by: Jing Zhang <renyu.zj@linux.alibaba.com> Link: https://lore.kernel.org/r/b8a14c14fcdf028939ebf57849863e8ae01743de.1686588640.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2023-06-16perf/arm-cmn: Revamp model detectionRobin Murphy
CMN implements a set of CoreSight-format peripheral ID registers which in principle we should be able to use to identify the hardware. However so far we have avoided trying to use the part number field since the TRMs have all described it as "configuration dependent". It turns out, though, that this is a quirk of the documentation generation process, and in fact the part number should always be a stable well-defined field which we can trust. To that end, revamp our model detection to rely less on ACPI/DT, and pave the way towards further using the hardware information as an identifier for userspace jevent metrics. This includes renaming the revision constants to maximise readability. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-and-tested-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Link: https://lore.kernel.org/r/3c791eaae814b0126f9adbd5419bfb4a600dade7.1686588640.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2023-06-16wifi: ray_cs: fix stringop-truncation GCC warningKalle Valo
GCC 12.2 with W=1 warns: drivers/net/wireless/legacy/ray_cs.c:630:17: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation] The driver uses SSID as a string which is just wrong, it should be treated as a byte array instead. But as the driver is ancient and most likely there are no users so convert it to use strscpy(). This makes sure that the string is NUL-terminated and also the warning is fixed. Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230613140918.389690-5-kvalo@kernel.org
2023-06-16wifi: hostap: fix stringop-truncations GCC warningKalle Valo
With GCC 13.1 and W=1 hostap has a warning: drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3633:17: warning: 'strncpy' specified bound 16 equals destination size [-Wstringop-truncation] fortify-string.h recommends not to use strncpy() so use strscpy() which fixes the warning. Also now it's guarenteed that the string is NUL-terminated. Compile tested only. Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230613140918.389690-4-kvalo@kernel.org
2023-06-16wifi: brcmsmac: fix gnu_printf warningsKalle Valo
With GCC 13.1 and W=1 brcmsmac has warnings like this: ./include/trace/stages/stage5_get_offsets.h:23:31: warning: function 'trace_event_get_offsets_brcms_dbg' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] Add a workaround which disables -Wsuggest-attribute=format in brcms_trace_brcmsmac_msg.h. I see similar workarounds in other drivers as well. Compile tested only. Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230613140918.389690-3-kvalo@kernel.org
2023-06-16wifi: brcmfmac: fix gnu_printf warningsKalle Valo
With GCC 13.1 and W=1 brcmfmac has warnings like this: ./include/trace/perf.h:26:16: warning: function 'perf_trace_brcmf_dbg' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] Add a workaround which disables -Wsuggest-attribute=format in tracepoint.h. I see similar workarounds in other drivers as well. Compile tested only. Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230613140918.389690-2-kvalo@kernel.org
2023-06-16perf/arm_dmc620: Add cpumaskXin Yang
Add a cpumask for the DMC620 PMU. As it is an uncore PMU, perf userspace tool only needs to open a single counter on the CPU specified by the CPU mask for each event on a given DMC620 device. Signed-off-by: Xin Yang <xin.yang@arm.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20230613013423.2078397-1-xin.yang@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2023-06-16x86/xen: Set default memory type for PV guests to WBJuergen Gross
When running as an unprivileged PV guest under Xen (not dom0), the default MTRR memory type should be write-back. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20230615123959.12298-1-jgross@suse.com
2023-06-16dt-bindings: gpio: Add Cirrus EP93xxNikita Shubin
Add YAML bindings for ep93xx SoC gpio controller. Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-06-16gpio: mpc8xxx: latch GPIOs state on module load when configured as outputMichal Smulski
Qoriq and related devices allow reading out state of GPIO set as output. However, currently on driver's init, all outputs are configured as driven low. So, any changes to GPIO confiuration will drive all pins (configured as output) as output-low. This patch latches state of output GPIOs before any GPIO configuration takes place. This preserves any output settings done prior to loading the driver (for example, by u-boot). Signed-off-by: Michal Smulski <michal.smulski@ooma.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-06-16selftests: gpio: gpio-sim: Use same variable name for sysfs pathnameAndy Shevchenko
SYSFS_PATH can be used locally and globally, especially that has the same content. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-06-16gpio: mlxbf3: Add gpio driver supportAsmaa Mnebhi
Add support for the BlueField-3 SoC GPIO driver. This driver configures and handles GPIO interrupts. It also enables a user to manipulate certain GPIO pins via libgpiod tools or other kernel drivers. The usables pins are defined via the "gpio-reserved-ranges" property. Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-06-16s390/uv: Update query for secret-UVCsSteffen Eiden
Update the query struct such that secret-UVC related information can be parsed. Add sysfs files for these new values. 'supp_add_secret_req_ver' notes the supported versions for the Add Secret UVC. Bit 0 indicates that version 0x100 is supported, bit 1 indicates 0x200, and so on. 'supp_add_secret_pcf' notes the supported plaintext flags for the Add Secret UVC. 'supp_secret_types' notes the supported types of secrets. Bit 0 indicates secret type 1, bit 1 indicates type 2, and so on. 'max_secrets' notes the maximum amount of secrets the secret store can store per pv guest. Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Link: https://lore.kernel.org/r/20230615100533.3996107-8-seiden@linux.ibm.com Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20230615100533.3996107-8-seiden@linux.ibm.com>
2023-06-16s390/uv: replace scnprintf with sysfs_emitSteffen Eiden
Replace scnprintf(page, PAGE_SIZE, ...) with the page size aware sysfs_emit(buf, ...) which adds some sanity checks. Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Link: https://lore.kernel.org/r/20230615100533.3996107-7-seiden@linux.ibm.com Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20230615100533.3996107-7-seiden@linux.ibm.com>
2023-06-16s390/uvdevice: Add 'Lock Secret Store' UVCSteffen Eiden
Userspace can call the Lock Secret Store Ultravisor Call using IOCTLs on the uvdevice. The Lock Secret Store UV call disables all additions of secrets for the future. The uvdevice is merely transporting the request from userspace to the Ultravisor. Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Link: https://lore.kernel.org/r/20230615100533.3996107-6-seiden@linux.ibm.com Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20230615100533.3996107-6-seiden@linux.ibm.com>
2023-06-16s390/uvdevice: Add 'List Secrets' UVCSteffen Eiden
Userspace can call the List Secrets Ultravisor Call using IOCTLs on the uvdevice. The List Secrets UV call lists the identifier of the secrets in the UV secret store. The uvdevice is merely transporting the request from userspace to Ultravisor. It's neither checking nor manipulating the request or response data. Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Link: https://lore.kernel.org/r/20230615100533.3996107-5-seiden@linux.ibm.com Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20230615100533.3996107-5-seiden@linux.ibm.com>
2023-06-16s390/uvdevice: Add 'Add Secret' UVCSteffen Eiden
Userspace can call the Add Secret Ultravisor Call using IOCTLs on the uvdevice. The Add Secret UV call sends an encrypted and cryptographically verified request to the Ultravisor. The request inserts a protected guest's secret into the Ultravisor for later use. The uvdevice is merely transporting the request from userspace to the Ultravisor. It's neither checking nor manipulating the request data. Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Link: https://lore.kernel.org/r/20230615100533.3996107-4-seiden@linux.ibm.com Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20230615100533.3996107-4-seiden@linux.ibm.com>
2023-06-16s390/uvdevice: Add info IOCTLSteffen Eiden
Add an IOCTL that allows userspace to find out which IOCTLs the uvdevice supports without trial and error. Explicitly expose the IOCTL nr for the request types. Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Link: https://lore.kernel.org/r/20230615100533.3996107-3-seiden@linux.ibm.com Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20230615100533.3996107-3-seiden@linux.ibm.com>
2023-06-16s390/uv: Always export uv_infoSteffen Eiden
KVM needs the struct's values to be able to provide PV support. The uvdevice is currently guest only and will need the struct's values for call support checking and potential future expansions. As uv.c is only compiled with CONFIG_PGSTE or CONFIG_PROTECTED_VIRTUALIZATION_GUEST we don't need a second check in the code. Users of uv_info will need to fence for these two config options for the time being. Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Link: https://lore.kernel.org/r/20230615100533.3996107-2-seiden@linux.ibm.com Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20230615100533.3996107-2-seiden@linux.ibm.com>
2023-06-16KVM: s390/diag: fix racy access of physical cpu number in diag 9c handlerChristian Borntraeger
We do check for target CPU == -1, but this might change at the time we are going to use it. Hold the physical target CPU in a local variable to avoid out-of-bound accesses to the cpu arrays. Cc: Pierre Morel <pmorel@linux.ibm.com> Fixes: 87e28a15c42c ("KVM: s390: diag9c (directed yield) forwarding") Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: Nico Boehr <nrb@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2023-06-16KVM: s390: vsie: fix the length of APCB bitmapPierre Morel
bit_and() uses the count of bits as the woking length. Fix the previous implementation and effectively use the right bitmap size. Fixes: 19fd83a64718 ("KVM: s390: vsie: allow CRYCB FORMAT-1") Fixes: 56019f9aca22 ("KVM: s390: vsie: Allow CRYCB FORMAT-2") Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Link: https://lore.kernel.org/kvm/20230511094719.9691-1-pmorel@linux.ibm.com/ Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2023-06-16Merge branches 'slab/for-6.5/prandom', 'slab/for-6.5/slab_no_merge' and ↵Vlastimil Babka
'slab/for-6.5/slab-deprecate' into slab/for-next Merge the feature branches scheduled for 6.5: - replace the usage of weak PRNGs, by David Keisar Schmidt - introduce the SLAB_NO_MERGE kmem_cache flag, by Jesper Dangaard Brouer - deprecate CONFIG_SLAB, with a planned removal, by myself
2023-06-16KVM: s390: selftests: add selftest for CMMA migrationNico Boehr
Add a selftest for CMMA migration on s390. The tests cover: - interaction of dirty tracking and migration mode, see my recent patch "KVM: s390: disable migration mode when dirty tracking is disabled" [1], - several invalid calls of KVM_S390_GET_CMMA_BITS, for example: invalid flags, CMMA support off, with/without peeking - ensure KVM_S390_GET_CMMA_BITS initally reports all pages as dirty, - ensure KVM_S390_GET_CMMA_BITS properly skips over holes in memslots, but also non-dirty pages Note that without the patch at [1] and the small fix in this series, the selftests will fail. [1] https://lore.kernel.org/all/20230127140532.230651-2-nrb@linux.ibm.com/ Signed-off-by: Nico Boehr <nrb@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20230324145424.293889-3-nrb@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> [frankja@linux.ibm.com: squashed 20230606150510.671301-1-nrb@linux.ibm.com / "KVM: s390: selftests: CMMA: don't run if CMMA not supported"] Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2023-06-16mm/slab_common: use SLAB_NO_MERGE instead of negative refcountVlastimil Babka
When CONFIG_MEMCG_KMEM is enabled, we disable cache merging for KMALLOC_NORMAL caches so they don't end up merged with a cache that uses ad-hoc __GFP_ACCOUNT when allocating. This was implemented by setting the refcount to -1, but now we have a proper SLAB_NO_MERGE flag, so use that instead. Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: David Rientjes <rientjes@google.com>
2023-06-16gpio: delay: Remove duplicative functionalityAndy Shevchenko
Now that GPIO aggregator supports a delay line, drop the duplicative functionality, i.e. the entire gpio-delay driver. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-06-16gpio: aggregator: Set up a parser of delay line parametersAndy Shevchenko
The aggregator mode can also handle properties of the platform, that do not belong to the GPIO controller itself. One of such a property is a signal delay line. Set up a parser to support it. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-06-16gpio: aggregator: Support delay for setting up individual GPIOsAndy Shevchenko
In some cases the GPIO may require an additional delay after setting its value. Add support for that into the GPIO forwarder code. This will be fully enabled for use in the following changes. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-06-16gpio: aggregator: Remove CONFIG_OF and of_match_ptr() protectionsAndy Shevchenko
They stop the driver being used with ACPI PRP0001 and are something I want to avoid being cut and paste into new drivers. Also include mod_devicetable.h as we struct of_device_id is defined in there. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-06-16x86/mm: Remove unused current_untag_mask()Borislav Petkov (AMD)
e0bddc19ba95 ("x86/mm: Reduce untagged_addr() overhead for systems without LAM") removed its only usage site so drop it. Move the tlbstate_untag_mask up in the header and drop the ugly ifdeffery as the unused declaration should be properly discarded. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lore.kernel.org/r/20230614174148.5439-1-bp@alien8.de
2023-06-16xfrm: Linearize the skb after offloading if needed.Sebastian Andrzej Siewior
With offloading enabled, esp_xmit() gets invoked very late, from within validate_xmit_xfrm() which is after validate_xmit_skb() validates and linearizes the skb if the underlying device does not support fragments. esp_output_tail() may add a fragment to the skb while adding the auth tag/ IV. Devices without the proper support will then send skb->data points to with the correct length so the packet will have garbage at the end. A pcap sniffer will claim that the proper data has been sent since it parses the skb properly. It is not affected with INET_ESP_OFFLOAD disabled. Linearize the skb after offloading if the sending hardware requires it. It was tested on v4, v6 has been adopted. Fixes: 7785bba299a8d ("esp: Add a software GRO codepath") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2023-06-16x86/fpu: Move FPU initialization into arch_cpu_finalize_init()Thomas Gleixner
Initializing the FPU during the early boot process is a pointless exercise. Early boot is convoluted and fragile enough. Nothing requires that the FPU is set up early. It has to be initialized before fork_init() because the task_struct size depends on the FPU register buffer size. Move the initialization to arch_cpu_finalize_init() which is the perfect place to do so. No functional change. This allows to remove quite some of the custom early command line parsing, but that's subject to the next installment. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224545.902376621@linutronix.de
2023-06-16x86/fpu: Mark init functions __initThomas Gleixner
No point in keeping them around. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224545.841685728@linutronix.de
2023-06-16x86/fpu: Remove cpuinfo argument from init functionsThomas Gleixner
Nothing in the call chain requires it Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224545.783704297@linutronix.de
2023-06-16x86/init: Initialize signal frame size lateThomas Gleixner
No point in doing this during really early boot. Move it to an early initcall so that it is set up before possible user mode helpers are started during device initialization. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224545.727330699@linutronix.de
2023-06-16init, x86: Move mem_encrypt_init() into arch_cpu_finalize_init()Thomas Gleixner
Invoke the X86ism mem_encrypt_init() from X86 arch_cpu_finalize_init() and remove the weak fallback from the core code. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224545.670360645@linutronix.de
2023-06-16init: Invoke arch_cpu_finalize_init() earlierThomas Gleixner
X86 is reworking the boot process so that initializations which are not required during early boot can be moved into the late boot process and out of the fragile and restricted initial boot phase. arch_cpu_finalize_init() is the obvious place to do such initializations, but arch_cpu_finalize_init() is invoked too late in start_kernel() e.g. for initializing the FPU completely. fork_init() requires that the FPU is initialized as the size of task_struct on X86 depends on the size of the required FPU register buffer. Fortunately none of the init calls between calibrate_delay() and arch_cpu_finalize_init() is relevant for the functionality of arch_cpu_finalize_init(). Invoke it right after calibrate_delay() where everything which is relevant for arch_cpu_finalize_init() has been set up already. No functional change intended. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://lore.kernel.org/r/20230613224545.612182854@linutronix.de
2023-06-16init: Remove check_bugs() leftoversThomas Gleixner
Everything is converted over to arch_cpu_finalize_init(). Remove the check_bugs() leftovers including the empty stubs in asm-generic, alpha, parisc, powerpc and xtensa. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Link: https://lore.kernel.org/r/20230613224545.553215951@linutronix.de
2023-06-16um/cpu: Switch to arch_cpu_finalize_init()Thomas Gleixner
check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Richard Weinberger <richard@nod.at> Link: https://lore.kernel.org/r/20230613224545.493148694@linutronix.de
2023-06-16sparc/cpu: Switch to arch_cpu_finalize_init()Thomas Gleixner
check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://lore.kernel.org/r/20230613224545.431995857@linutronix.de
2023-06-16sh/cpu: Switch to arch_cpu_finalize_init()Thomas Gleixner
check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224545.371697797@linutronix.de
2023-06-16mips/cpu: Switch to arch_cpu_finalize_init()Thomas Gleixner
check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224545.312438573@linutronix.de
2023-06-16m68k/cpu: Switch to arch_cpu_finalize_init()Thomas Gleixner
check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/20230613224545.254342916@linutronix.de
2023-06-16loongarch/cpu: Switch to arch_cpu_finalize_init()Thomas Gleixner
check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224545.195288218@linutronix.de
2023-06-16ia64/cpu: Switch to arch_cpu_finalize_init()Thomas Gleixner
check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224545.137045745@linutronix.de
2023-06-16ARM: cpu: Switch to arch_cpu_finalize_init()Thomas Gleixner
check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224545.078124882@linutronix.de
2023-06-16x86/cpu: Switch to arch_cpu_finalize_init()Thomas Gleixner
check_bugs() is a dumping ground for finalizing the CPU bringup. Only parts of it has to do with actual CPU bugs. Split it apart into arch_cpu_finalize_init() and cpu_select_mitigations(). Fixup the bogus 32bit comments while at it. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230613224545.019583869@linutronix.de
2023-06-16init: Provide arch_cpu_finalize_init()Thomas Gleixner
check_bugs() has become a dumping ground for all sorts of activities to finalize the CPU initialization before running the rest of the init code. Most are empty, a few do actual bug checks, some do alternative patching and some cobble a CPU advertisement string together.... Aside of that the current implementation requires duplicated function declaration and mostly empty header files for them. Provide a new function arch_cpu_finalize_init(). Provide a generic declaration if CONFIG_ARCH_HAS_CPU_FINALIZE_INIT is selected and a stub inline otherwise. This requires a temporary #ifdef in start_kernel() which will be removed along with check_bugs() once the architectures are converted over. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230613224544.957805717@linutronix.de
2023-06-16sfc: do not try to call tc functions when CONFIG_SFC_SRIOV=nEdward Cree
Functions efx_tc_netdev_event and efx_tc_netevent_event do not exist in that case as object files tc_bindings.o and tc_encap_actions.o are not built, so the calls to them from ef100_netdev_event and ef100_netevent_event cause link errors. Wrap the corresponding header files (tc_bindings.h, tc_encap_actions.h) with #if IS_ENABLED(CONFIG_SFC_SRIOV), and add an #else with static inline stubs for these two functions. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306102026.ISK5JfUQ-lkp@intel.com/ Fixes: 7e5e7d800011 ("sfc: neighbour lookup for TC encap action offload") Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Reviewed-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-16s390/net: lcs: use IS_ENABLED() for kconfig detectionRandy Dunlap
When CONFIG_ETHERNET=m or CONFIG_FDDI=m, lcs.s has build errors or warnings: ../drivers/s390/net/lcs.c:40:2: error: #error Cannot compile lcs.c without some net devices switched on. 40 | #error Cannot compile lcs.c without some net devices switched on. ../drivers/s390/net/lcs.c: In function 'lcs_startlan_auto': ../drivers/s390/net/lcs.c:1601:13: warning: unused variable 'rc' [-Wunused-variable] 1601 | int rc; Solve this by using IS_ENABLED(CONFIG_symbol) instead of ifdef CONFIG_symbol. The latter only works for builtin (=y) values while IS_ENABLED() works for builtin or modular values. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Alexandra Winter <wintera@linux.ibm.com> Cc: Wenjia Zhang <wenjia@linux.ibm.com> Cc: linux-s390@vger.kernel.org Cc: netdev@vger.kernel.org Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-16Merge tag 'asoc-fix-v6.4-rc6-2' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.4 A couple more fixes for v6.4, one fixing a misleading error log and another stopping us seeing spurious failures setting the master volume on some Tegra systems introduced by a change to how we calculate delay times.
generated by cgit (git 2.34.1) at 2025-10-03 00:39:55 +0000