- 11 3月, 2022 1 次提交
-
-
由 Dmitry Baryshkov 提交于
The function device_pm_check_callbacks() can be called under the spin lock (in the reported case it happens from genpd_add_device() -> dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes. However this function uncoditionally uses spin_lock_irq() / spin_unlock_irq(), thus not preserving the CPU flags. Use the irqsave/irqrestore instead. The backtrace for the reference: [ 2.752010] ------------[ cut here ]------------ [ 2.756769] raw_local_irq_restore() called with IRQs enabled [ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50 [ 2.772338] Modules linked in: [ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684 [ 2.781384] Freeing initrd memory: 46024K [ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50 [ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50 [ 2.785846] sp : ffff80000805b7d0 [ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002 [ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800 [ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00 [ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff [ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7 [ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8 [ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0 [ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0 [ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000 [ 2.889774] Call trace: [ 2.892290] warn_bogus_irq_restore+0x34/0x50 [ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0 [ 2.901690] genpd_unlock_spin+0x20/0x30 [ 2.905724] genpd_add_device+0x100/0x2d0 [ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c [ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190 [ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0 [ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30 [ 2.929102] psci_dt_attach_cpu+0x24/0x90 [ 2.933230] psci_cpuidle_probe+0x2d4/0x46c [ 2.937534] platform_probe+0x68/0xe0 [ 2.941304] really_probe.part.0+0x9c/0x2fc [ 2.945605] __driver_probe_device+0x98/0x144 [ 2.950085] driver_probe_device+0x44/0x15c [ 2.954385] __device_attach_driver+0xb8/0x120 [ 2.958950] bus_for_each_drv+0x78/0xd0 [ 2.962896] __device_attach+0xd8/0x180 [ 2.966843] device_initial_probe+0x14/0x20 [ 2.971144] bus_probe_device+0x9c/0xa4 [ 2.975092] device_add+0x380/0x88c [ 2.978679] platform_device_add+0x114/0x234 [ 2.983067] platform_device_register_full+0x100/0x190 [ 2.988344] psci_idle_init+0x6c/0xb0 [ 2.992113] do_one_initcall+0x74/0x3a0 [ 2.996060] kernel_init_freeable+0x2fc/0x384 [ 3.000543] kernel_init+0x28/0x130 [ 3.004132] ret_from_fork+0x10/0x20 [ 3.007817] irq event stamp: 319826 [ 3.011404] hardirqs last enabled at (319825): [<ffffd40e7eda0268>] __up_console_sem+0x78/0x84 [ 3.020332] hardirqs last disabled at (319826): [<ffffd40e7fd6d9d8>] el1_dbg+0x24/0x8c [ 3.028458] softirqs last enabled at (318312): [<ffffd40e7ec90410>] _stext+0x410/0x588 [ 3.036678] softirqs last disabled at (318299): [<ffffd40e7ed1bf68>] __irq_exit_rcu+0x158/0x174 [ 3.045607] ---[ end trace 0000000000000000 ]--- Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 05 3月, 2022 1 次提交
-
-
由 Douglas Anderson 提交于
The PM Runtime docs say: Drivers in ->remove() callback should undo the runtime PM changes done in ->probe(). Usually this means calling pm_runtime_disable(), pm_runtime_dont_use_autosuspend() etc. From grepping code, it's clear that many people aren't aware of the need to call pm_runtime_dont_use_autosuspend(). When brainstorming solutions, one idea that came up was to leverage the new-ish devm_pm_runtime_enable() function. The idea here is that: * When the devm action is called we know that the driver is being removed. It's the perfect time to undo the use_autosuspend. * The code of pm_runtime_dont_use_autosuspend() already handles the case of being called when autosuspend wasn't enabled. Suggested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NDouglas Anderson <dianders@chromium.org> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 2月, 2022 1 次提交
-
-
由 Mårten Lindahl 提交于
When unbinding/binding a driver with DMA mapped memory, the DMA map is not freed before the driver is reloaded. This leads to a memory leak when the DMA map is overwritten when reprobing the driver. This can be reproduced with a platform driver having a dma-range: dummy { ... #address-cells = <0x2>; #size-cells = <0x2>; ranges; dma-ranges = <...>; ... }; and then unbinding/binding it: ~# echo soc:dummy >/sys/bus/platform/drivers/<driver>/unbind DMA map object 0xffffff800b0ae540 still being held by &pdev->dev ~# echo soc:dummy >/sys/bus/platform/drivers/<driver>/bind ~# echo scan > /sys/kernel/debug/kmemleak ~# cat /sys/kernel/debug/kmemleak unreferenced object 0xffffff800b0ae540 (size 64): comm "sh", pid 833, jiffies 4295174550 (age 2535.352s) hex dump (first 32 bytes): 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 80 00 00 00 00 00 00 00 80 00 00 00 00 ................ backtrace: [<ffffffefd1694708>] create_object.isra.0+0x108/0x344 [<ffffffefd1d1a850>] kmemleak_alloc+0x8c/0xd0 [<ffffffefd167e2d0>] __kmalloc+0x440/0x6f0 [<ffffffefd1a960a4>] of_dma_get_range+0x124/0x220 [<ffffffefd1a8ce90>] of_dma_configure_id+0x40/0x2d0 [<ffffffefd198b68c>] platform_dma_configure+0x5c/0xa4 [<ffffffefd198846c>] really_probe+0x8c/0x514 [<ffffffefd1988990>] __driver_probe_device+0x9c/0x19c [<ffffffefd1988cd8>] device_driver_attach+0x54/0xbc [<ffffffefd1986634>] bind_store+0xc4/0x120 [<ffffffefd19856e0>] drv_attr_store+0x30/0x44 [<ffffffefd173c9b0>] sysfs_kf_write+0x50/0x60 [<ffffffefd173c1c4>] kernfs_fop_write_iter+0x124/0x1b4 [<ffffffefd16a013c>] new_sync_write+0xdc/0x160 [<ffffffefd16a256c>] vfs_write+0x23c/0x2a0 [<ffffffefd16a2758>] ksys_write+0x64/0xec To prevent this we should free the dma_range_map when the device is released. Fixes: e0d07278 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Cc: stable <stable@vger.kernel.org> Suggested-by: NRob Herring <robh@kernel.org> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NMårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20220216094128.4025861-1-marten.lindahl@axis.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 17 2月, 2022 1 次提交
-
-
由 Prasad Kumpatla 提交于
With the existing logic where clear_ack is true (HW doesn’t support auto clear for ICR), interrupt clear register reset is not handled properly. Due to this only the first interrupts get processed properly and further interrupts are blocked due to not resetting interrupt clear register. Example for issue case where Invert_ack is false and clear_ack is true: Say Default ISR=0x00 & ICR=0x00 and ISR is triggered with 2 interrupts making ISR = 0x11. Step 1: Say ISR is set 0x11 (store status_buff = ISR). ISR needs to be cleared with the help of ICR once the Interrupt is processed. Step 2: Write ICR = 0x11 (status_buff), this will clear the ISR to 0x00. Step 3: Issue - In the existing code, ICR is written with ICR = ~(status_buff) i.e ICR = 0xEE -> This will block all the interrupts from raising except for interrupts 0 and 4. So expectation here is to reset ICR, which will unblock all the interrupts. if (chip->clear_ack) { if (chip->ack_invert && !ret) ........ else if (!ret) ret = regmap_write(map, reg, ~data->status_buf[i]); So writing 0 and 0xff (when ack_invert is true) should have no effect, other than clearing the ACKs just set. Fixes: 3a6f0fb7 ("regmap: irq: Add support to clear ack registers") Signed-off-by: NPrasad Kumpatla <quic_pkumpatl@quicinc.com> Reviewed-by: NCharles Keepax <ckeepax@opensource.cirrus.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20220217085007.30218-1-quic_pkumpatl@quicinc.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 08 2月, 2022 1 次提交
-
-
由 Rafael J. Wysocki 提交于
After commit e3728b50 ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") wakeup interrupts occurring immediately after the one discarded by acpi_s2idle_wake() may be missed. Moreover, if the SCI triggers again immediately after the rearming in acpi_s2idle_wake(), that wakeup may be missed too. The problem is that pm_system_irq_wakeup() only calls pm_system_wakeup() when pm_wakeup_irq is 0, but that's not the case any more after the interrupt causing acpi_s2idle_wake() to run until pm_wakeup_irq is cleared by the pm_wakeup_clear() call in s2idle_loop(). However, there may be wakeup interrupts occurring in that time frame and if that happens, they will be missed. To address that issue first move the clearing of pm_wakeup_irq to the point at which it is known that the interrupt causing acpi_s2idle_wake() to tun will be discarded, before rearming the SCI for wakeup. Moreover, because that only reduces the size of the time window in which the issue may manifest itself, allow pm_system_irq_wakeup() to register two second wakeup interrupts in a row and, when discarding the first one, replace it with the second one. [Of course, this assumes that only one wakeup interrupt can be discarded in one go, but currently that is the case and I am not aware of any plans to change that.] Fixes: e3728b50 ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 1月, 2022 1 次提交
-
-
由 Xiaoming Ni 提交于
Patch series "sysctl: 3rd set of kernel/sysctl cleanups", v2. This is the third set of patches to help address cleaning the kitchen seink in kernel/sysctl.c and to move sysctls away to where they are actually implemented / used. This patch (of 8): kernel/sysctl.c is a kitchen sink where everyone leaves their dirty dishes, this makes it very difficult to maintain. To help with this maintenance let's start by moving sysctls to places where they actually belong. The proc sysctl maintainers do not want to know what sysctl knobs you wish to add for your own piece of code, we just care about the core logic. So move the firmware configuration sysctl table to the only place where it is used, and make it clear that if sysctls are disabled this is not used. [akpm@linux-foundation.org: export register_firmware_config_sysctl and unregister_firmware_config_sysctl to modules] [akpm@linux-foundation.org: use EXPORT_SYMBOL_NS_GPL instead] [sfr@canb.auug.org.au: fix that so it compiles] Link: https://lkml.kernel.org/r/20211201160626.401d828d@canb.auug.org.au [mcgrof@kernel.org: major commit log update to justify the move] Link: https://lkml.kernel.org/r/20211124231435.1445213-1-mcgrof@kernel.org Link: https://lkml.kernel.org/r/20211124231435.1445213-2-mcgrof@kernel.orgSigned-off-by: NXiaoming Ni <nixiaoming@huawei.com> Signed-off-by: NLuis Chamberlain <mcgrof@kernel.org> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Cc: Kees Cook <keescook@chromium.org> Cc: Iurii Zaikin <yzaikin@google.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Stephen Kitt <steve@sk2.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Petr Mladek <pmladek@suse.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: John Ogness <john.ogness@linutronix.de> Cc: Douglas Gilbert <dgilbert@interlog.com> Cc: James E.J. Bottomley <jejb@linux.ibm.com> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Lukas Middendorf <kernel@tuxforce.de> Cc: Antti Palosaari <crope@iki.fi> Cc: Amir Goldstein <amir73il@gmail.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: Clemens Ladisch <clemens@ladisch.de> Cc: David Airlie <airlied@linux.ie> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Joel Becker <jlbec@evilplan.org> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Julia Lawall <julia.lawall@inria.fr> Cc: Mark Fasheh <mark@fasheh.com> Cc: Paul Turner <pjt@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Phillip Potter <phil@philpotter.co.uk> Cc: Qing Wang <wangqing@vivo.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 1月, 2022 3 次提交
-
-
由 Kefeng Wang 提交于
With NEED_PER_CPU_PAGE_FIRST_CHUNK enabled, we need a function to populate pte, this patch adds a generic pcpu populate pte function, pcpu_populate_pte(), which is marked __weak and used on most architectures, but it is overridden on x86, which has its own implementation. Link: https://lkml.kernel.org/r/20211216112359.103822-5-wangkefeng.wang@huawei.comSigned-off-by: NKefeng Wang <wangkefeng.wang@huawei.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Dennis Zhou <dennis@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Christoph Lameter <cl@linux.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Will Deacon <will@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Kefeng Wang 提交于
With the previous patch, we could add a generic pcpu first chunk allocate and free function to cleanup the duplicated definations on each architecture. Link: https://lkml.kernel.org/r/20211216112359.103822-4-wangkefeng.wang@huawei.comSigned-off-by: NKefeng Wang <wangkefeng.wang@huawei.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Dennis Zhou <dennis@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Christoph Lameter <cl@linux.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Will Deacon <will@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Kefeng Wang 提交于
Add pcpu_fc_cpu_to_node_fn_t and pass it into pcpu_fc_alloc_fn_t, pcpu first chunk allocation will call it to alloc memblock on the corresponding node by it, this is prepare for the next patch. Link: https://lkml.kernel.org/r/20211216112359.103822-3-wangkefeng.wang@huawei.comSigned-off-by: NKefeng Wang <wangkefeng.wang@huawei.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Dennis Zhou <dennis@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Christoph Lameter <cl@linux.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 1月, 2022 1 次提交
-
-
由 NeilBrown 提交于
Prior to Linux v5.4 devtmpfs used mount_single() which treats the given mount options as "remount" options, so it updates the configuration of the single super_block on each mount. Since that was changed, the mount options used for devtmpfs are ignored. This is a regression which affect systemd - which mounts devtmpfs with "-o mode=755,size=4m,nr_inodes=1m". This patch restores the "remount" effect by calling reconfigure_single() Fixes: d401727e ("devtmpfs: don't mix {ramfs,shmem}_fill_super() with mount_single()") Acked-by: NChristian Brauner <christian.brauner@ubuntu.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: NNeilBrown <neilb@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 08 1月, 2022 3 次提交
-
-
由 Masahiro Yamada 提交于
The previous commit fixed up all shell scripts to not include include/config/auto.conf. Now that include/config/auto.conf is only included by Makefiles, we can change it into a more Make-friendly form. Previously, Kconfig output string values enclosed with double-quotes (both in the .config and include/config/auto.conf): CONFIG_X="foo bar" Unlike shell, Make handles double-quotes (and single-quotes as well) verbatim. We must rip them off when used. There are some patterns: [1] $(patsubst "%",%,$(CONFIG_X)) [2] $(CONFIG_X:"%"=%) [3] $(subst ",,$(CONFIG_X)) [4] $(shell echo $(CONFIG_X)) These are not only ugly, but also fragile. [1] and [2] do not work if the value contains spaces, like CONFIG_X=" foo bar " [3] does not work correctly if the value contains double-quotes like CONFIG_X="foo\"bar" [4] seems to work better, but has a cost of forking a process. Anyway, quoted strings were always PITA for our Makefiles. This commit changes Kconfig to stop quoting in include/config/auto.conf. These are the string type symbols referenced in Makefiles or scripts: ACPI_CUSTOM_DSDT_FILE ARC_BUILTIN_DTB_NAME ARC_TUNE_MCPU BUILTIN_DTB_SOURCE CC_IMPLICIT_FALLTHROUGH CC_VERSION_TEXT CFG80211_EXTRA_REGDB_KEYDIR EXTRA_FIRMWARE EXTRA_FIRMWARE_DIR EXTRA_TARGETS H8300_BUILTIN_DTB INITRAMFS_SOURCE LOCALVERSION MODULE_SIG_HASH MODULE_SIG_KEY NDS32_BUILTIN_DTB NIOS2_DTB_SOURCE OPENRISC_BUILTIN_DTB SOC_CANAAN_K210_DTB_SOURCE SYSTEM_BLACKLIST_HASH_LIST SYSTEM_REVOCATION_KEYS SYSTEM_TRUSTED_KEYS TARGET_CPU UNUSED_KSYMS_WHITELIST XILINX_MICROBLAZE0_FAMILY XILINX_MICROBLAZE0_HW_VER XTENSA_VARIANT_NAME I checked them one by one, and fixed up the code where necessary. Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
-
由 Mark Brown 提交于
Signed-off-by: NMark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220107191145.813876-1-broonie@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>
-
由 Fabio Estevam 提交于
Since commit cffa4b21 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev"), the following debugfs error is seen on i.MX boards: debugfs: Directory 'dummy-iomuxc-gpr@20e0000' with parent 'regmap' already present! In the attempt to fix the memory leak, the above commit added a NULL check for map->debugfs_name. For the first debufs entry, map->debugfs_name is NULL and then the new name is allocated via kasprintf(). For the second debugfs entry, map->debugfs_name() is no longer NULL, so it will keep using the old entry name and the duplicate name error is seen. Quoting Mark Brown: "That means that if the device gets freed we'll end up with the old debugfs file hanging around pointing at nothing. ... To be more explicit this means we need a call to regmap_debugfs_exit() which will clean up all the existing debugfs stuff before we loose references to it." Call regmap_debugfs_exit() prior to regmap_debugfs_init() to fix the problem. Tested on i.MX6Q and i.MX6SX boards. Fixes: cffa4b21 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev") Suggested-by: NMark Brown <broonie@kernel.org> Signed-off-by: NFabio Estevam <festevam@denx.de> Link: https://lore.kernel.org/r/20220107163307.335404-1-festevam@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
-
- 06 1月, 2022 2 次提交
-
-
由 Lu Baolu 提交于
If a driver cannot be bound to a device, the correct bus notifier order should be: - BUS_NOTIFY_BIND_DRIVER: driver is about to be bound - BUS_NOTIFY_DRIVER_NOT_BOUND: driver failed to be bound or no notifier if the failure happens before the actual binding. The really_probe() notifies a BUS_NOTIFY_DRIVER_NOT_BOUND event without a BUS_NOTIFY_BIND_DRIVER if .dma_configure() returns failure. This change makes the notifiers in order. Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20211231033901.2168664-3-baolu.lu@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Lu Baolu 提交于
The driver_sysfs_remove() should be called after driver_sysfs_add() in really_probe(). The out-of-order driver_sysfs_remove() tries to remove some nonexistent nodes under the device and driver sysfs nodes. This is allowed, hence this change doesn't fix any problem, just a cleanup. Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20211231033901.2168664-2-baolu.lu@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 1月, 2022 1 次提交
-
-
由 Ingo Molnar 提交于
This was the only usage of <linux/kref_api.h> in <linux/kobject_api.h>, so we'll able to decouple the two after this change. Signed-off-by: NIngo Molnar <mingo@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 30 12月, 2021 1 次提交
-
-
由 Kees Cook 提交于
devtmpfs is writable. Add the noexec and nosuid as default mount flags to prevent code execution from /dev. The systems who don't use systemd and who rely on CONFIG_DEVTMPFS_MOUNT=y are the ones to be protected by this patch. Other systems are fine with the udev solution. No sane program should be relying on executing from /dev. So this patch reduces the attack surface. It doesn't prevent any specific attack, but it reduces the possibility that someone can use /dev as a place to put executable code. Chrome OS has been carrying this patch for several years. It seems trivial and simple solution to improve the protection of /dev when CONFIG_DEVTMPFS_MOUNT=y. Original patch: https://lore.kernel.org/lkml/20121120215059.GA1859@www.outflux.net/ Cc: ellyjones@chromium.org Cc: Kay Sievers <kay@vrfy.org> Cc: Roland Eggner <edvx1@systemanalysen.net> Co-developed-by: NMuhammad Usama Anjum <usama.anjum@collabora.com> Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NMuhammad Usama Anjum <usama.anjum@collabora.com> Link: https://lore.kernel.org/r/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 29 12月, 2021 1 次提交
-
-
由 Mark-PK Tsai 提交于
Simplify async probe test code by using ktime_ms_delta(). Signed-off-by: NMark-PK Tsai <mark-pk.tsai@mediatek.com> Link: https://lore.kernel.org/r/20211228092707.29987-1-mark-pk.tsai@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 28 12月, 2021 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
There is no need to pass the pointer to the kset in the struct kset_uevent_ops callbacks as no one uses it, so just remove that pointer entirely. Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NWedson Almeida Filho <wedsonaf@google.com> Link: https://lore.kernel.org/r/20211227163924.3970661-1-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 27 12月, 2021 1 次提交
-
-
由 Wedson Almeida Filho 提交于
This way instances of kobj_type (which contain function pointers) can be stored in .rodata, which means that they cannot be [easily/accidentally] modified at runtime. Signed-off-by: NWedson Almeida Filho <wedsonaf@google.com> Link: https://lore.kernel.org/r/20211224231345.777370-1-wedsonaf@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 23 12月, 2021 2 次提交
-
-
由 Rafael J. Wysocki 提交于
Notice that pm_runtime_put_suppliers() cannot be called with disabled interrupts, because it may sleep (due to the device links read locking in the non-SRCU case), and so it can use spin_lock_irq() and spin_unlock_irq() for the locking. Update the function accordingly and while at it move the "put" local variable in it into the inner block where it is used. This change is not expected to have any visible functional impact. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Clément Léger 提交于
nargs_prop refers to a property located in the reference that is found within the nargs property. Use the correct reference node in call to property_entry_read_int_array() to retrieve the correct nargs value. Fixes: b06184ac ("software node: Add software_node_get_reference_args()") Signed-off-by: NClément Léger <clement.leger@bootlin.com> Reviewed-by: NSakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: NDaniel Scally <djrscally@gmail.com> Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 12月, 2021 1 次提交
-
-
由 Johan Hovold 提交于
Add an explicit comment to document that the reference initialised by platform_device_register() needs to be released by a call to platform_device_put() also when registration fails (cf. device_register()). Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211222104213.5673-1-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 12月, 2021 1 次提交
-
-
由 Anand Ashok Dumbre 提交于
This patch introduces a new helper routine - fwnode_iomap(), which allows to map the memory mapped IO for a given device node. This implementation does not cover the ACPI case and may be expanded in the future. The main purpose here is to be able to develop resource provider agnostic drivers. Suggested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NAnand Ashok Dumbre <anand.ashok.dumbre@xilinx.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20211203212358.31444-2-anand.ashok.dumbre@xilinx.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 18 12月, 2021 6 次提交
-
-
由 Sakari Ailus 提交于
fwnode_graph_get_remote_node() is only used by the tegra-video driver. Convert it to use newer fwnode_graph_get_endpoint_by_id() and drop now-unused fwnode_graph_get_remote_node(). Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Sakari Ailus 提交于
Now that we have fwnode_graph_for_each_endpoint() macro, use it instead of calling fwnode_graph_get_next_endpoint() directly. It manages the iterator variable for the user without manual intervention. Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Sakari Ailus 提交于
Add fwnode_graph_get_endpoint_count() function to provide generic implementation of of_graph_get_endpoint_count(). The former by default only counts endpoints to available devices which is consistent with the rest of the fwnode graph API. By providing FWNODE_GRAPH_DEVICE_DISABLED flag, also unconnected endpoints and endpoints to disabled devices are counted. Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Sakari Ailus 提交于
FWNODE_GRAPH_DEVICE_DISABLED flag was meant for also returning endpoints connected to disabled devices, but it also may return endpoints that are not connected. Fix this in documentation. Also fwnode_graph_get_endpoint_by_id() was affeced by this. Also improve the language a little bit. Fixes: 0fcc2bdc ("device property: Add fwnode_graph_get_endpoint_by_id()") Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Sakari Ailus 提交于
For each endpoint it encounters, fwnode_graph_devcon_match() checks whether the endpoint's remote port parent device is available. If it is not, it ignores the endpoint but does not put the reference to the remote endpoint port parent fwnode. For available devices the fwnode handle reference is put as expected. Put the reference for unavailable devices now. Fixes: 637e9e52 ("device connection: Find device connections also from device graphs") Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
Commit 2aa36604 ("PM: sleep: Avoid calling put_device() under dpm_list_mtx") forgot to update the while () loop termination condition to also break the loop if error is nonzero, which causes the loop to become infinite if device_prepare() returns an error for one device. Add the missing !error check. Fixes: 2aa36604 ("PM: sleep: Avoid calling put_device() under dpm_list_mtx") Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reported-by: NThomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: NThomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org> Cc: All applicable <stable@vger.kernel.org>
-
- 17 12月, 2021 10 次提交
-
-
由 Rafael J. Wysocki 提交于
Because refcount_dec_not_one() returns true if the target refcount becomes saturated, it is generally unsafe to use its return value as a loop termination condition, but that is what happens when a device link's supplier device is released during runtime PM suspend operations and on device link removal. To address this, introduce pm_runtime_release_supplier() to be used in the above cases which will check the supplier device's runtime PM usage counter in addition to the refcount_dec_not_one() return value, so the loop can be terminated in case the rpm_active refcount value becomes invalid, and update the code in question to use it as appropriate. This change is not expected to have any visible functional impact. Reported-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
-
由 Rafael J. Wysocki 提交于
In some cases (for example, during system-wide suspend and resume of devices) it is useful to know whether or not runtime PM has ever been enabled for a given device and, if so, what the runtime PM status of it had been right before runtime PM was disabled for it last time. For this reason, introduce a new struct dev_pm_info field called last_status that will be used for capturing the runtime PM status of the device when its power.disable_depth counter changes from 0 to 1. The new field will be set to RPM_INVALID to start with and whenever power.disable_depth changes from 1 to 0, so it will be valid only when runtime PM of the device is currently disabled, but it has been enabled at least once. Immediately use power.last_status in rpm_resume() to make it handle the case when PM runtime is disabled for the device, but its runtime PM status is RPM_ACTIVE more consistently. Namely, make it return 1 if power.last_status is also equal to RPM_ACTIVE in that case (the idea being that if the status was RPM_ACTIVE last time when power.disable_depth was changing from 0 to 1 and it is still RPM_ACTIVE, it can be assumed to reflect what happened to the device last time when it was using runtime PM) and -EACCES otherwise. Update the documentation to provide a description of last_status and change the description of pm_runtime_resume() in it to reflect the new behavior of rpm_active(). While at it, rearrange the code in pm_runtime_enable() to be more straightforward and replace the WARN() macro in it with a pr_warn() invocation which is less disruptive. Link: https://lore.kernel.org/linux-pm/20211026222626.39222-1-ulf.hansson@linaro.org/t/#uReviewed-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Thomas Gleixner 提交于
The allocation code is overly complex. It tries to have the MSI index space packed, which is not working when an interrupt is freed. There is no requirement for this. The only requirement is that the MSI index is unique. Move the MSI descriptor allocation into msi_domain_populate_irqs() and use the Linux interrupt number as MSI index which fulfils the unique requirement. This requires to lock the MSI descriptors which makes the lock order reverse to the regular MSI alloc/free functions vs. the domain mutex. Assign a seperate lockdep class for these MSI device domains. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NNishanth Menon <nm@ti.com> Reviewed-by: NJason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20211206210748.956731741@linutronix.de
-
由 Thomas Gleixner 提交于
Use the core functionality for platform MSI interrupt domains. The platform device MSI interrupt domains will be converted in a later step. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NNishanth Menon <nm@ti.com> Reviewed-by: NJason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20211206210748.903173257@linutronix.de
-
由 Thomas Gleixner 提交于
It's only required when MSI is in use. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NMichael Kelley <mikelley@microsoft.com> Tested-by: NNishanth Menon <nm@ti.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NJason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20211206210747.650487479@linutronix.de
-
由 Thomas Gleixner 提交于
Use the common msi_index member and get rid of the pointless wrapper struct. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NNishanth Menon <nm@ti.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NJason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20211210221814.413638645@linutronix.de
-
由 Thomas Gleixner 提交于
Storing the platform private data in a MSI descriptor is sloppy at best. The data belongs to the device and not to the descriptor. Add a pointer to struct msi_device_data and store the pointer there. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NNishanth Menon <nm@ti.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NJason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20211210221814.287680528@linutronix.de
-
由 Thomas Gleixner 提交于
It's hard to distinguish what platform_msi_domain_alloc() and platform_msi_domain_alloc_irqs() are about. Make the distinction more explicit and add comments which explain the use cases properly. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NNishanth Menon <nm@ti.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NJason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20211210221814.228706214@linutronix.de
-
由 Thomas Gleixner 提交于
Set the domain info flag and remove the local sysfs code. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NNishanth Menon <nm@ti.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NJason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20211210221814.109408832@linutronix.de
-
由 Thomas Gleixner 提交于
Allocate the MSI device data on first invocation of the allocation function for platform MSI private data. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NNishanth Menon <nm@ti.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NJason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20211210221813.805529729@linutronix.de
-