kernel/linux.git/drivers/base, branch v6.3.6

regmap: cache: Return error in cache sync operations for REGCACHE_NONE

2023-05-24T16:30:01+00:00

[ Upstream commit fd883d79e4dcd2417c2b80756f22a2ff03b0f6e0 ] There is no sense in doing a cache sync on REGCACHE_NONE regmaps. Instead of panicking the kernel due to missing cache_ops, return an error to client driver. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20230313071812.13577-1-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

arch_topology: Remove early cacheinfo error message if -ENOENT

2023-05-11T14:17:38+00:00

commit 3522340199cc060b70f0094e3039bdb43c3f6ee1 upstream. fetch_cache_info() tries to get the number of cache leaves/levels for each CPU in order to pre-allocate memory for cacheinfo struct. Allocating this memory later triggers a: 'BUG: sleeping function called from invalid context' in PREEMPT_RT kernels. If there is no cache related information available in DT or ACPI, fetch_cache_info() fails and an error message is printed: 'Early cacheinfo failed, ret = ...' Not having cache information should be a valid configuration. Remove the error message if fetch_cache_info() fails with -ENOENT. Suggested-by: Conor Dooley Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ Signed-off-by: Pierre Gondois Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20230414081453.244787-4-pierre.gondois@arm.com Signed-off-by: Sudeep Holla Cc: Florian Fainelli Signed-off-by: Greg Kroah-Hartman

cacheinfo: Check cache properties are present in DT

2023-05-11T14:17:26+00:00

[ Upstream commit cde0fbff07eff7e4e0e85fa053fe19a24c86b1e0 ] If a Device Tree (DT) is used, the presence of cache properties is assumed. Not finding any is not considered. For arm64 platforms, cache information can be fetched from the clidr_el1 register. Checking whether cache information is available in the DT allows to switch to using clidr_el1. init_of_cache_level() \-of_count_cache_leaves() will assume there a 2 cache leaves (L1 data/instruction caches), which can be different from clidr_el1 information. cache_setup_of_node() tries to read cache properties in the DT. If there are none, this is considered a success. Knowing no information was available would allow to switch to using clidr_el1. Fixes: de0df442ee49 ("cacheinfo: Check 'cache-unified' property to count cache leaves") Reported-by: Alexandre Ghiti Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ Signed-off-by: Pierre Gondois Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20230414081453.244787-3-pierre.gondois@arm.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

cacheinfo: Check sib_leaf in cache_leaves_are_shared()

2023-05-11T14:17:26+00:00

[ Upstream commit 7a306e3eabf2b2fd8cffa69b87b32dbf814d79ce ] If there is no ACPI/DT information, it is assumed that L1 caches are private and L2 (and higher) caches are shared. A cache is 'shared' between two CPUs if it is accessible from these two CPUs. Each CPU owns a representation (i.e. has a dedicated cacheinfo struct) of the caches it has access to. cache_leaves_are_shared() tries to identify whether two representations are designating the same actual cache. In cache_leaves_are_shared(), if 'this_leaf' is a L2 cache (or higher) and 'sib_leaf' is a L1 cache, the caches are detected as shared as only this_leaf's cache level is checked. This is leads to setting sib_leaf as being shared with another CPU, which is incorrect as this is a L1 cache. Check 'sib_leaf->level'. Also update the comment as the function is called when populating 'shared_cpu_map'. Fixes: f16d1becf96f ("cacheinfo: Use cache identifiers to check if the caches are shared if available") Signed-off-by: Pierre Gondois Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20230414081453.244787-2-pierre.gondois@arm.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

tick/nohz: Fix cpu_is_hotpluggable() by checking with nohz subsystem

2023-05-11T14:16:49+00:00

commit 58d7668242647e661a20efe065519abd6454287e upstream. For CONFIG_NO_HZ_FULL systems, the tick_do_timer_cpu cannot be offlined. However, cpu_is_hotpluggable() still returns true for those CPUs. This causes torture tests that do offlining to end up trying to offline this CPU causing test failures. Such failure happens on all architectures. Fix the repeated error messages thrown by this (even if the hotplug errors are harmless) by asking the opinion of the nohz subsystem on whether the CPU can be hotplugged. [ Apply Frederic Weisbecker feedback on refactoring tick_nohz_cpu_down(). ] For drivers/base/ portion: Acked-by: Greg Kroah-Hartman Acked-by: Frederic Weisbecker Cc: Frederic Weisbecker Cc: "Paul E. McKenney" Cc: Zhouyi Zhou Cc: Will Deacon Cc: Marc Zyngier Cc: rcu Cc: stable@vger.kernel.org Fixes: 2987557f52b9 ("driver-core/cpu: Expose hotpluggability to the rest of the kernel") Signed-off-by: Paul E. McKenney Signed-off-by: Joel Fernandes (Google) Signed-off-by: Greg Kroah-Hartman

driver core: Don't require dynamic_debug for initcall_debug probe timing

2023-04-30T23:32:26+00:00

commit e2f06aa885081e1391916367f53bad984714b4db upstream. Don't require the use of dynamic debug (or modification of the kernel to add a #define DEBUG to the top of this file) to get the printk message about driver probe timing. This printk is only emitted when initcall_debug is enabled on the kernel commandline, and it isn't immediately obvious that you have to do something else to debug boot timing issues related to driver probe. Add a comment too so it doesn't get converted back to pr_debug(). Fixes: eb7fbc9fb118 ("driver core: Add missing '\n' in log messages") Cc: stable Cc: Christophe JAILLET Cc: Brian Norris Reviewed-by: Brian Norris Acked-by: Randy Dunlap Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20230412225842.3196599-1-swboyd@chromium.org Signed-off-by: Greg Kroah-Hartman

cacheinfo: Fix LLC is not exported through sysfs

2023-03-29T10:04:10+00:00

After entering 6.3-rc1 the LLC cacheinfo is not exported on our ACPI based arm64 server. This is because the LLC cacheinfo is partly reset when secondary CPUs boot up. On arm64 the primary cpu will allocate and setup cacheinfo: init_cpu_topology() for_each_possible_cpu() fetch_cache_info() // Allocate cacheinfo and init levels detect_cache_attributes() cache_shared_cpu_map_setup() if (!last_level_cache_is_valid()) // not valid, setup LLC cache_setup_properties() // setup LLC On secondary CPU boot up: detect_cache_attributes() populate_cache_leaves() get_cache_type() // Get cache type from clidr_el1, // for LLC type=CACHE_TYPE_NOCACHE cache_shared_cpu_map_setup() if (!last_level_cache_is_valid()) // Valid and won't go to this branch, // leave LLC's type=CACHE_TYPE_NOCACHE The last_level_cache_is_valid() use cacheinfo->{attributes, fw_token} to test it's valid or not, but populate_cache_leaves() will only reset LLC's type, so we won't try to re-setup LLC's type and leave it CACHE_TYPE_NOCACHE and won't export it through sysfs. This patch tries to fix this by not re-populating the cache leaves if the LLC is valid. Fixes: 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU") Signed-off-by: Yicong Yang Reviewed-by: Pierre Gondois Reviewed-by: Sudeep Holla Link: https://lore.kernel.org/r/20230328114915.33340-1-yangyicong@huawei.com Signed-off-by: Greg Kroah-Hartman

Merge tag 'irq-urgent-2023-03-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2023-03-05T19:19:16+00:00

Pull irq updates from Thomas Gleixner: "A set of updates for the interrupt susbsystem: - Prevent possible NULL pointer derefences in irq_data_get_affinity_mask() and irq_domain_create_hierarchy() - Take the per device MSI lock before invoking code which relies on it being hold - Make sure that MSI descriptors are unreferenced before freeing them. This was overlooked when the platform MSI code was converted to use core infrastructure and results in a fals positive warning - Remove dead code in the MSI subsystem - Clarify the documentation for pci_msix_free_irq() - More kobj_type constification" * tag 'irq-urgent-2023-03-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq/msi, platform-msi: Ensure that MSI descriptors are unreferenced genirq/msi: Drop dead domain name assignment irqdomain: Add missing NULL pointer check in irq_domain_create_hierarchy() genirq/irqdesc: Make kobj_type structures constant PCI/MSI: Clarify usage of pci_msix_free_irq() genirq/msi: Take the per-device MSI lock before validating the control structure genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()

Merge tag 'driver-core-6.3-rc1_2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2023-03-02T17:32:34+00:00

Pull driver core fixes from Greg KH: "Here is another small set of driver core patches. They resolve some reported problems with the previous driver core patches that are in your tree. They solve a problem with the bus_type cleanup as reported and fixed by Geert, and two fw_devlink changes to make debugging problems easier. There is one known outstanding problem with the fw_deflink changes in your tree that is still being worked on, and it looks like a clk core change will be submitted soon for that, probably after 6.3-rc1. All three of these have been in linux-next with no reported problems (only reports that they fixed problems)" * tag 'driver-core-6.3-rc1_2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: driver core: fw_devlink: Print full path and name of fwnode driver core: fw_devlink: Avoid spurious error message driver core: bus: Handle early calls to bus_to_subsys()

genirq/msi, platform-msi: Ensure that MSI descriptors are unreferenced

2023-03-02T17:09:44+00:00

Miquel reported a warning in the MSI core which is triggered when interrupts are freed via platform_msi_device_domain_free(). This code got reworked to use core functions for freeing the MSI descriptors, but nothing took care to clear the msi_desc->irq entry, which then triggers the warning in msi_free_msi_desc() which uses desc->irq to validate that the descriptor has been torn down. The same issue exists in msi_domain_populate_irqs(). Up to the point that msi_free_msi_descs() grew a warning for this case, this went un-noticed. Provide the counterpart of msi_domain_populate_irqs() and invoke it in platform_msi_device_domain_free() before freeing the interrupts and MSI descriptors and also in the error path of msi_domain_populate_irqs(). Fixes: 2f2940d16823 ("genirq/msi: Remove filter from msi_free_descs_free_range()") Reported-by: Miquel Raynal Signed-off-by: Thomas Gleixner Tested-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87mt4wkwnv.ffs@tglx