summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-08-17ARM: OMAP2+: Fix refcount leak in omapdss_init_ofMiaoqian Lin1-0/+2
[ Upstream commit 9705db1eff38d6b9114121f9e253746199b759c9 ] omapdss_find_dss_of_node() calls of_find_compatible_node() to get device node. of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() in later error path and normal path. Fixes: e0c827aca0730 ("drm/omap: Populate DSS children in omapdss driver") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Message-Id: <20220601044858.3352-1-linmq006@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: qcom: mdm9615: add missing PMIC GPIO regKrzysztof Kozlowski1-0/+1
[ Upstream commit dc590cdc31f636ea15658f1206c3e380a53fb78e ] 'reg' property is required in SSBI children: qcom-mdm9615-wp8548-mangoh-green.dtb: gpio@150: 'reg' is a required property Fixes: 2c5e596524e7 ("ARM: dts: Add MDM9615 dtsi") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220507194913.261121-11-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: dts: qcom: sdm845-akatsuki: Round down l22a regulator voltageMarijn Suijten1-2/+3
[ Upstream commit 4148a9eeb15152865d60b0913d96beb7ca166f9a ] 2700000 is not a multiple of pmic4_pldo's step size of 8000 (with base voltage 1664000), resulting in pm8998-rpmh-regulators not probing. Just as we did with MSM8998's Sony Yoshino Poplar [1], round the voltages down to err on the cautious side and leave a comment in place to document this discrepancy wrt downstream sources. [1]: https://lore.kernel.org/linux-arm-msm/20220507153627.1478268-1-marijn.suijten@somainline.org/ Fixes: 30a7f99befc6 ("arm64: dts: qcom: Add support for SONY Xperia XZ2 / XZ2C / XZ3 (Tama platform)") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220620211212.269956-1-marijn.suijten@somainline.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17block: fix infinite loop for invalid zone appendKeith Busch1-3/+0
[ Upstream commit b82d9fa257cb3725c49d94d2aeafc4677c34448a ] Returning 0 early from __bio_iov_append_get_pages() for the max_append_sectors warning just creates an infinite loop since 0 means success, and the bio will never fill from the unadvancing iov_iter. We could turn the return into an error value, but it will already be turned into an error value later on, so just remove the warning. Clearly no one ever hit it anyway. Fixes: 0512a75b98f84 ("block: Introduce REQ_OP_ZONE_APPEND") Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20220610195830.3574005-2-kbusch@fb.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17spi: s3c64xx: constify fsd_spi_port_configKrzysztof Kozlowski1-1/+1
[ Upstream commit a813c47d22b0a0c51567292bc198a39bdcdc3799 ] All struct s3c64xx_spi_port_config should be const. Fixes: 4ebb15a15799 ("spi: s3c64xx: Add spi port configuration for Tesla FSD SoC") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220627094541.95166-1-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17soc: fsl: guts: machine variable might be unsetMichael Walle1-1/+1
[ Upstream commit ab3f045774f704c4e7b6a878102f4e9d4ae7bc74 ] If both the model and the compatible properties are missing, then machine will not be set. Initialize it with NULL. Fixes: 34c1c21e94ac ("soc: fsl: fix section mismatch build warnings") Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: dts: qcom: sc7180: Remove ipa_fw_mem node on trogdorStephen Boyd1-0/+1
[ Upstream commit e60414644cf3a703e10ed4429c15263095945ffe ] We don't use this carveout on trogdor boards, and having it defined in the sc7180 SoC file causes an overlap message to be printed at boot. OF: reserved mem: OVERLAP DETECTED! memory@86000000 (0x0000000086000000--0x000000008ec00000) overlaps with memory@8b700000 (0x000000008b700000--0x000000008b710000) Delete the node in the trogdor dtsi file to fix the overlap problem and remove the error message. Cc: Alex Elder <elder@linaro.org> Cc: Matthias Kaehlcke <mka@chromium.org> Fixes: 310b266655a3 ("arm64: dts: qcom: sc7180: define ipa_fw_mem node") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220517193307.3034602-1-swboyd@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17locking/lockdep: Fix lockdep_init_map_*() confusionPeter Zijlstra2-16/+21
[ Upstream commit eae6d58d67d9739be5f7ae2dbead1d0ef6528243 ] Commit dfd5e3f5fe27 ("locking/lockdep: Mark local_lock_t") added yet another lockdep_init_map_*() variant, but forgot to update all the existing users of the most complicated version. This could lead to a loss of lock_type and hence an incorrect report. Given the relative rarity of both local_lock and these annotations, this is unlikely to happen in practise, still, best fix things. Fixes: dfd5e3f5fe27 ("locking/lockdep: Mark local_lock_t") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/YqyEDtoan20K0CVD@worktop.programming.kicks-ass.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: cpufeature: Allow different PMU versions in ID_DFR0_EL1Alexandru Elisei1-1/+1
[ Upstream commit 506506cad3947b942425b119ffa2b06715d5d804 ] Commit b20d1ba3cf4b ("arm64: cpufeature: allow for version discrepancy in PMU implementations") made it possible to run Linux on a machine with PMUs with different versions without tainting the kernel. The patch relaxed the restriction only for the ID_AA64DFR0_EL1.PMUVer field, and missed doing the same for ID_DFR0_EL1.PerfMon , which also reports the PMU version, but for the AArch32 state. For example, with Linux running on two clusters with different PMU versions, the kernel is tainted when bringing up secondaries with the following message: [ 0.097027] smp: Bringing up secondary CPUs ... [..] [ 0.142805] Detected PIPT I-cache on CPU4 [ 0.142805] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_DFR0_EL1. Boot CPU: 0x00000004011088, CPU4: 0x00000005011088 [ 0.143555] CPU features: Unsupported CPU feature variation detected. [ 0.143702] GICv3: CPU4: found redistributor 10000 region 0:0x000000002f180000 [ 0.143702] GICv3: CPU4: using allocated LPI pending table @0x00000008800d0000 [ 0.144888] CPU4: Booted secondary processor 0x0000010000 [0x410fd0f0] The boot CPU implements FEAT_PMUv3p1 (ID_DFR0_EL1.PerfMon, bits 27:24, is 0b0100), but CPU4, part of the other cluster, implements FEAT_PMUv3p4 (ID_DFR0_EL1.PerfMon = 0b0101). Treat the PerfMon field as FTR_NONSTRICT and FTR_EXACT to pass the sanity check and to match how PMUVer is treated for the 64bit ID register. Fixes: b20d1ba3cf4b ("arm64: cpufeature: allow for version discrepancy in PMU implementations") Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> Link: https://lore.kernel.org/r/20220617111332.203061-1-alexandru.elisei@arm.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: select TRACE_IRQFLAGS_NMI_SUPPORTMark Rutland1-0/+1
[ Upstream commit 3381da254fab37ba08c4b7c4f19b4ee28b1a27ec ] Due to an oversight, on arm64 lockdep IRQ state tracking doesn't work as intended in NMI context. This demonstrably results in bogus warnings from lockdep, and in theory could mask a variety of issues. On arm64, we've consistently tracked IRQ flag state for NMIs (and saved/restored the state of the interrupted context) since commit: f0cd5ac1e4c53cb6 ("arm64: entry: fix NMI {user, kernel}->kernel transitions") That commit fixed most lockdep issues with NMI by virtue of the save/restore of the lockdep state of the interrupted context. However, for lockdep IRQ state tracking to consistently take effect in NMI context it has been necessary to select TRACE_IRQFLAGS_NMI_SUPPORT since commit: ed00495333ccc80f ("locking/lockdep: Fix TRACE_IRQFLAGS vs. NMIs") As arm64 does not select TRACE_IRQFLAGS_NMI_SUPPORT, this means that the lockdep state can be stale in NMI context, and some uses of that state can consume stale data. When an NMI is taken arm64 entry code will call arm64_enter_nmi(). This will enter NMI context via __nmi_enter() before calling lockdep_hardirqs_off() to inform lockdep that IRQs have been masked. Where TRACE_IRQFLAGS_NMI_SUPPORT is not selected, lockdep_hardirqs_off() will not update lockdep state if called in NMI context. Thus if IRQs were enabled in the original context, lockdep will continue to believe that IRQs are enabled despite the call to lockdep_hardirqs_off(). However, the lockdep_assert_*() checks do take effect in NMI context, and will consume the stale lockdep state. If an NMI is taken from a context which had IRQs enabled, and during the handling of the NMI something calls lockdep_assert_irqs_disabled(), this will result in a spurious warning based upon the stale lockdep state. This can be seen when using perf with GICv3 pseudo-NMIs. Within the perf NMI handler we may attempt a uaccess to record the userspace callchain, and is this faults the el1_abort() call in the nested context will call exit_to_kernel_mode() when returning, which has a lockdep_assert_irqs_disabled() assertion: | # ./perf record -a -g sh | ------------[ cut here ]------------ | WARNING: CPU: 0 PID: 164 at arch/arm64/kernel/entry-common.c:73 exit_to_kernel_mode+0x118/0x1ac | Modules linked in: | CPU: 0 PID: 164 Comm: perf Not tainted 5.18.0-rc5 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 004003c5 (nzcv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : exit_to_kernel_mode+0x118/0x1ac | lr : el1_abort+0x80/0xbc | sp : ffff8000080039f0 | pmr_save: 000000f0 | x29: ffff8000080039f0 x28: ffff6831054e4980 x27: ffff683103adb400 | x26: 0000000000000000 x25: 0000000000000001 x24: 0000000000000001 | x23: 00000000804000c5 x22: 00000000000000c0 x21: 0000000000000001 | x20: ffffbd51e635ec44 x19: ffff800008003a60 x18: 0000000000000000 | x17: ffffaadf98d23000 x16: ffff800008004000 x15: 0000ffffd14f25c0 | x14: 0000000000000000 x13: 00000000000018eb x12: 0000000000000040 | x11: 000000000000001e x10: 000000002b820020 x9 : 0000000100110000 | x8 : 000000000045cac0 x7 : 0000ffffd14f25c0 x6 : ffffbd51e639b000 | x5 : 00000000000003e5 x4 : ffffbd51e58543b0 x3 : 0000000000000001 | x2 : ffffaadf98d23000 x1 : ffff6831054e4980 x0 : 0000000100110000 | Call trace: | exit_to_kernel_mode+0x118/0x1ac | el1_abort+0x80/0xbc | el1h_64_sync_handler+0xa4/0xd0 | el1h_64_sync+0x74/0x78 | __arch_copy_from_user+0xa4/0x230 | get_perf_callchain+0x134/0x1e4 | perf_callchain+0x7c/0xa0 | perf_prepare_sample+0x414/0x660 | perf_event_output_forward+0x80/0x180 | __perf_event_overflow+0x70/0x13c | perf_event_overflow+0x1c/0x30 | armv8pmu_handle_irq+0xe8/0x160 | armpmu_dispatch_irq+0x2c/0x70 | handle_percpu_devid_fasteoi_nmi+0x7c/0xbc | generic_handle_domain_nmi+0x3c/0x60 | gic_handle_irq+0x1dc/0x310 | call_on_irq_stack+0x2c/0x54 | do_interrupt_handler+0x80/0x94 | el1_interrupt+0xb0/0xe4 | el1h_64_irq_handler+0x18/0x24 | el1h_64_irq+0x74/0x78 | lockdep_hardirqs_off+0x50/0x120 | trace_hardirqs_off+0x38/0x214 | _raw_spin_lock_irq+0x98/0xa0 | pipe_read+0x1f8/0x404 | new_sync_read+0x140/0x150 | vfs_read+0x190/0x1dc | ksys_read+0xdc/0xfc | __arm64_sys_read+0x20/0x30 | invoke_syscall+0x48/0x114 | el0_svc_common.constprop.0+0x158/0x17c | do_el0_svc+0x28/0x90 | el0_svc+0x60/0x150 | el0t_64_sync_handler+0xa4/0x130 | el0t_64_sync+0x19c/0x1a0 | irq event stamp: 483 | hardirqs last enabled at (483): [<ffffbd51e636aa24>] _raw_spin_unlock_irqrestore+0xa4/0xb0 | hardirqs last disabled at (482): [<ffffbd51e636acd0>] _raw_spin_lock_irqsave+0xb0/0xb4 | softirqs last enabled at (468): [<ffffbd51e5216f58>] put_cpu_fpsimd_context+0x28/0x70 | softirqs last disabled at (466): [<ffffbd51e5216ed4>] get_cpu_fpsimd_context+0x0/0x5c | ---[ end trace 0000000000000000 ]--- Note that as lockdep_assert_irqs_disabled() uses WARN_ON_ONCE(), and this uses a BRK, the warning is logged with the real PSTATE at the time of the warning, which clearly has DAIF.I set, meaning IRQs (and pseudo-NMIs) were definitely masked and the warning is spurious. Fix this by selecting TRACE_IRQFLAGS_NMI_SUPPORT such that the existing entry tracking takes effect, as we had originally intended when the arm64 entry code was fixed for transitions to/from NMI. Arguably the lockdep_assert_*() functions should have the same NMI checks as the rest of the code to prevent spurious warnings when TRACE_IRQFLAGS_NMI_SUPPORT is not selected, but the real fix for any architecture is to explicitly handle the transitions to/from NMI in the entry code. Fixes: f0cd5ac1e4c5 ("arm64: entry: fix NMI {user, kernel}->kernel transitions") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20220511131733.4074499-3-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: dts: mt8192: Fix idle-states entry-methodNícolas F. R. A. Prado1-1/+1
[ Upstream commit 2e599740f7e423ee89fb027896cb2635dd43784f ] The entry-method property of the idle-states node should be "psci" as described in the idle-states binding, since this is already the value of enable-method in the CPU nodes. Fix it to get rid of a dtbs_check warning. Fixes: 9260918d3a4f ("arm64: dts: mt8192: Add cpu-idle-states") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220617233150.2466344-3-nfraprado@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: dts: mt8192: Fix idle-states nodes naming schemeNícolas F. R. A. Prado1-12/+12
[ Upstream commit 399e23ad51caaf62400a531c9268ad3c453c3d76 ] Tweak the name of the idle-states subnodes so that they follow the binding pattern, getting rid of dtbs_check warnings. Only the usage of "-" in the name was necessary, but "off" was also exchanged for "sleep" since that seems to be a more common wording in other dts files. Fixes: 9260918d3a4f ("arm64: dts: mt8192: Add cpu-idle-states") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220617233150.2466344-2-nfraprado@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: ast2600-evb-a1: fix board compatibleKrzysztof Kozlowski1-0/+1
[ Upstream commit 33c39140cc298e0d4e36083cb9a665a837773a60 ] The AST2600 EVB A1 board should have dedicated compatible. Fixes: a72955180372 ("ARM: dts: aspeed: ast2600evb: Add dts file for A1 and A0") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220529104928.79636-6-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: ast2600-evb: fix board compatibleKrzysztof Kozlowski1-1/+1
[ Upstream commit aa5e06208500a0db41473caebdee5a2e81d5a277 ] The AST2600 EVB board should have dedicated compatible. Fixes: 2ca5646b5c2f ("ARM: dts: aspeed: Add AST2600 and EVB") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220529104928.79636-5-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: ast2500-evb: fix board compatibleKrzysztof Kozlowski1-1/+1
[ Upstream commit 30b276fca5c0644f3cb17bceb1bd6a626c670184 ] The AST2500 EVB board should have dedicated compatible. Fixes: 02440622656d ("arm/dst: Add Aspeed ast2500 device tree") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220529104928.79636-4-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17x86/pmem: Fix platform-device leak in error pathJohan Hovold1-1/+6
[ Upstream commit 229e73d46994f15314f58b2d39bf952111d89193 ] Make sure to free the platform device in the unlikely event that registration fails. Fixes: 7a67832c7e44 ("libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20220620140723.9810-1-johan@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17Revert "ARM: dts: imx6qdl-apalis: Avoid underscore in node name"Max Krummenacher1-2/+2
[ Upstream commit 9c0919acb3fa7c1a24e384ff912f2d88f060c373 ] The STMPE MFD device binding requires the child node to have a fixed name, i.e. with '_', not '-'. Otherwise the stmpe_adc, stmpe_touchscreen drivers will not be probed. Fixes: 56086b5e804f ("ARM: dts: imx6qdl-apalis: Avoid underscore in node name") Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: dts: renesas: Fix thermal-sensors on single-zone sensorsGeert Uytterhoeven2-2/+2
[ Upstream commit 62e8a53431145e06e503b71625a34eaa87b72b2c ] "make dtbs_check": arch/arm64/boot/dts/renesas/r8a774c0-cat874.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[74], [0]] is too long arch/arm64/boot/dts/renesas/r8a774c0-ek874.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[79], [0]] is too long arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[82], [0]] is too long arch/arm64/boot/dts/renesas/r8a774c0-ek874-mipi-2.1.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[87], [0]] is too long arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[105], [0]] is too long From schema: Documentation/devicetree/bindings/thermal/thermal-zones.yaml Indeed, the thermal sensors on R-Car E3 and RZ/G2E support only a single zone, hence #thermal-sensor-cells = <0>. Fix this by dropping the bogus zero cell from the thermal sensor specifiers. Fixes: 8fa7d18f9ee2dc20 ("arm64: dts: renesas: r8a77990: Create thermal zone to support IPA") Fixes: 8438bfda9d768157 ("arm64: dts: renesas: r8a774c0: Create thermal zone to support IPA") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/28b812fdd1fc3698311fac984ab8b91d3d655c1c.1655301684.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17soc: amlogic: Fix refcount leak in meson-secure-pwrc.cLiang He1-1/+3
[ Upstream commit d18529a4c12f66d83daac78045ea54063bd43257 ] In meson_secure_pwrc_probe(), there is a refcount leak in one fail path. Signed-off-by: Liang He <windhl@126.com> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Fixes: b3dde5013e13 ("soc: amlogic: Add support for Secure power domains controller") Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20220616144915.3988071-1-windhl@126.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17soc: renesas: r8a779a0-sysc: Fix A2DP1 and A2CV[2357] PDR valuesGeert Uytterhoeven1-5/+5
[ Upstream commit bccceabb92ce8eb78bbf2de08308e2cc2761a2e5 ] The PDR values for the A2DP1 and A2CV[2357] power areas on R-Car V3U are incorrect (copied-and-pasted from A2DP0 and A2CV[0146]). Fix them. Reported-by: Renesas Vietnam via Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Fixes: 1b4298f000064cc2 ("soc: renesas: r8a779a0-sysc: Add r8a779a0 support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/87bc2e70ba4082970cf8c65871beae4be3503189.1654696188.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: imx7-colibri-eval-v3: correct can controller commentMarcel Ziswiler1-1/+1
[ Upstream commit 32f054fef145878c5331f9dd343014970a15ebfa ] Correct CAN controller comment. It is a MCP2515 rather than a mpc258x. Fixes: 66d59b678a87 ("ARM: dts: imx7-colibri: add MCP2515 CAN controller") Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: imx7-colibri: move aliases, chosen, extcon and gpio-keysMarcel Ziswiler3-49/+32
[ Upstream commit 0ef1969ea5699b00394e1a8c8c7f927b2d0bc5bb ] Move aliases, chosen, extcon and gpio-keys to module-level device tree given they are standard Colibri functionalities. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: imx7-colibri: improve wake-up with gpio keyOleksandr Suvorov2-2/+2
[ Upstream commit fd5d2974652c96935d94301af6eaf6b3585ab330 ] The pin GPIO1_IO01 externally pulls down, it is required to sequentially connect this pin (signal WAKE_MICO#) to +3v3 and then disconnect it to trigger a wakeup interrupt. Adding the flag GPIO_PULL_DOWN allows the system to be woken up just connecting the pin GPIO1_IO01 to +3v3. Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: imx7-colibri: add usb dual-role switching using extconPhilippe Schenker2-3/+10
[ Upstream commit 136f88458d829987548b3321e7122e05acd78dd9 ] Add USB dual-role switching using extcon. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: imx7-colibri: overhaul display/touch functionalityMarcel Ziswiler7-121/+197
[ Upstream commit dbeb8e72cc51536a70313e6d523dcb1429b40477 ] Rename display interface to match other modules to make it easier to use device tree overlays. The parallel RGB interface (lcdif) and all related stuff turn on in a device tree overlay. Keep them disabled in the main devicetree. As these subsystems are provided by module and not a part of boards, move their definitions into the module-level devicetree. Disable ad7879 touchscreen which turns on in a devic tree overlay. Remains it disabled in the main devicetree. Move Atmel MXT capacitive touch controller device tree nodes from carrier board to module level and add iomux pinctl groups for both the Capacitive Touch Adapter (using SODIMM 28/30) and the capacitive touch connector as found on later carrier boards (using SODIMM 106/107). Keep touchscreen and display nodes enabled for NAND based i.MX 7 modules, since device tree overlays are not yet supported. For the Colibri Evaluation Board keep the Capacitive Touch Adapter node disabled and PWM2, PWM3 enabled instead. For eMMC based modules keep nodes disabled to work in conjunction with device tree overlays. Add the iomuxc pinctrl group for the LVDS transceiver related signals to use it in a device tree overlay. While at it also alphabetically re=order them properties. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: imx7d-colibri-emmc: add cpu1 supplyMarcel Ziswiler1-0/+4
[ Upstream commit ba28db60d34271e8a3cf4d7158d71607e8b1e57f ] Each cpu-core is supposed to list its supply separately, add supply for cpu1. Fixes: 2d7401f8632f ("ARM: dts: imx7d: Add cpu1 supply") Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ACPI: processor/idle: Annotate more functions to live in cpuidle sectionGuilherme G. Piccoli1-3/+3
[ Upstream commit 409dfdcaffb266acfc1f33529a26b1443c9332d4 ] Commit 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus") introduced a new text section called cpuidle; with that, we have a mechanism to add idling functions in such section and skip them from nmi_backtrace output, since they're useless and potentially flooding for such report. Happens that inlining might cause some real idle functions to end-up outside of such section; this is currently the case of ACPI processor_idle driver; the functions acpi_idle_enter_* do inline acpi_idle_do_entry(), hence they stay out of the cpuidle section. Fix that by marking such functions to also live in the cpuidle section. Fixes: 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus") Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: bcm: Fix refcount leak in bcm_kona_smc_initMiaoqian Lin1-0/+1
[ Upstream commit cb23389a2458c2e4bfd6c86a513cbbe1c4d35e76 ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: b8eb35fd594a ("ARM: bcm281xx: Add L2 cache enable code") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17spi: spi-altera-dfl: Fix an error handling pathChristophe JAILLET1-9/+5
[ Upstream commit 8e3ca32f46994e74b7f43c57731150b2aedb2630 ] The spi_alloc_master() call is not undone in all error handling paths. Moreover, there is no .remove function to release the allocated memory. In order to fix both this issues, switch to devm_spi_alloc_master(). This allows further simplification of the probe. Fixes: ba2fc167e944 ("spi: altera: Add DFL bus driver for Altera API Controller") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/0607bb59f4073f86abe5c585d35245aef0b045c6.1653805901.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: dts: renesas: beacon: Fix regulator node namesGeert Uytterhoeven1-3/+3
[ Upstream commit 7512af9f78dedea7e04225f665dad6750df7d095 ] Currently there are two nodes named "regulator_camera". This causes the former to be overwritten by the latter. Fix this by renaming them to unique names, using the preferred hyphen instead of an underscore. While at it, update the name of the audio regulator (which was added in the same commit) to use a hyphen. Fixes: a1d8a344f1ca0709 ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/a9ac82bdf108162487289d091c53a9b3de393f13.1652263918.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17meson-mx-socinfo: Fix refcount leak in meson_mx_socinfo_initMiaoqian Lin1-0/+1
[ Upstream commit a2106f38077e78afcb4bf98fdda3e162118cfb3d ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 5e68c0fc8df8 ("soc: amlogic: Add Meson6/Meson8/Meson8b/Meson8m2 SoC Information driver") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20220524065729.33689-1-linmq006@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17wait: Fix __wait_event_hrtimeout for RT/DL tasksJuri Lelli1-4/+5
[ Upstream commit cceeeb6a6d02e7b9a74ddd27a3225013b34174aa ] Changes to hrtimer mode (potentially made by __hrtimer_init_sleeper on PREEMPT_RT) are not visible to hrtimer_start_range_ns, thus not accounted for by hrtimer_start_expires call paths. In particular, __wait_event_hrtimeout suffers from this problem as we have, for example: fs/aio.c::read_events wait_event_interruptible_hrtimeout __wait_event_hrtimeout hrtimer_init_sleeper_on_stack <- this might "mode |= HRTIMER_MODE_HARD" on RT if task runs at RT/DL priority hrtimer_start_range_ns WARN_ON_ONCE(!(mode & HRTIMER_MODE_HARD) ^ !timer->is_hard) fires since the latter doesn't see the change of mode done by init_sleeper Fix it by making __wait_event_hrtimeout call hrtimer_sleeper_start_expires, which is aware of the special RT/DL case, instead of hrtimer_start_range_ns. Reported-by: Bruno Goncalves <bgoncalv@redhat.com> Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Daniel Bristot de Oliveira <bristot@kernel.org> Reviewed-by: Valentin Schneider <vschneid@redhat.com> Link: https://lore.kernel.org/r/20220627095051.42470-1-juri.lelli@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17kasan: test: Silence GCC 12 warningsKees Cook1-0/+10
[ Upstream commit aaf50b1969d7933a51ea421b11432a7fb90974e3 ] GCC 12 continues to get smarter about array accesses. The KASAN tests are expecting to explicitly test out-of-bounds conditions at run-time, so hide the variable from GCC, to avoid warnings like: ../lib/test_kasan.c: In function 'ksize_uaf': ../lib/test_kasan.c:790:61: warning: array subscript 120 is outside array bounds of 'void[120]' [-Warray-bounds] 790 | KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)ptr)[size]); | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~ ../lib/test_kasan.c:97:9: note: in definition of macro 'KUNIT_EXPECT_KASAN_FAIL' 97 | expression; \ | ^~~~~~~~~~ Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: kasan-dev@googlegroups.com Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220608214024.1068451-1-keescook@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17io_uring: fix io_uring_cqe_overflow trace formatDylan Yudaken1-1/+1
[ Upstream commit 9b26e811e934eebda59362c9a03d082852552574 ] Make the trace format consistent with io_uring_complete for cflags Signed-off-by: Dylan Yudaken <dylany@fb.com> Link: https://lore.kernel.org/r/20220630091231.1456789-12-dylany@fb.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17selinux: Add boundary check in put_entry()Xiu Jianfeng1-0/+2
[ Upstream commit 15ec76fb29be31df2bccb30fc09875274cba2776 ] Just like next_entry(), boundary check is necessary to prevent memory out-of-bound access. Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17selinux: fix memleak in security_read_state_kernel()Xiu Jianfeng1-1/+8
[ Upstream commit 73de1befcc53a7c68b0c5e76b9b5ac41c517760f ] In this function, it directly returns the result of __security_read_policy without freeing the allocated memory in *data, cause memory leak issue, so free the memory if __security_read_policy failed. Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> [PM: subject line tweak] Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17PM: hibernate: defer device probing when resuming from hibernationTetsuo Handa1-1/+12
[ Upstream commit 8386c414e27caba8501119948e9551e52b527f59 ] syzbot is reporting hung task at misc_open() [1], for there is a race window of AB-BA deadlock which involves probe_count variable. Currently wait_for_device_probe() from snapshot_open() from misc_open() can sleep forever with misc_mtx held if probe_count cannot become 0. When a device is probed by hub_event() work function, probe_count is incremented before the probe function starts, and probe_count is decremented after the probe function completed. There are three cases that can prevent probe_count from dropping to 0. (a) A device being probed stopped responding (i.e. broken/malicious hardware). (b) A process emulating a USB device using /dev/raw-gadget interface stopped responding for some reason. (c) New device probe requests keeps coming in before existing device probe requests complete. The phenomenon syzbot is reporting is (b). A process which is holding system_transition_mutex and misc_mtx is waiting for probe_count to become 0 inside wait_for_device_probe(), but the probe function which is called from hub_event() work function is waiting for the processes which are blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface. This patch mitigates (b) by deferring wait_for_device_probe() from snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that the possibility of (b) remains as long as any thread which is emulating a USB device via /dev/raw-gadget interface can be blocked by uninterruptible blocking operations (e.g. mutex_lock()). Please also note that (a) and (c) are not addressed. Regarding (c), we should change the code to wait for only one device which contains the image for resuming from hibernation. I don't know how to address (a), for use of timeout for wait_for_device_probe() might result in loss of user data in the image. Maybe we should require the userland to wait for the image device before opening /dev/snapshot interface. Link: https://syzkaller.appspot.com/bug?extid=358c9ab4c93da7b7238c [1] Reported-by: syzbot <syzbot+358c9ab4c93da7b7238c@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: syzbot <syzbot+358c9ab4c93da7b7238c@syzkaller.appspotmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17hwmon: (sht15) Fix wrong assumptions in device remove callbackUwe Kleine-König1-11/+6
[ Upstream commit 7d4edccc9bbfe1dcdff641343f7b0c6763fbe774 ] Taking a lock at the beginning of .remove() doesn't prevent new readers. With the existing approach it can happen, that a read occurs just when the lock was taken blocking the reader until the lock is released at the end of the remove callback which then accessed *data that is already freed then. To actually fix this problem the hwmon core needs some adaption. Until this is implemented take the optimistic approach of assuming that all readers are gone after hwmon_device_unregister() and sysfs_remove_group() as most other drivers do. (And once the core implements that, taking the lock would deadlock.) So drop the lock, move the reset to after device unregistration to keep the device in a workable state until it's deregistered. Also add a error message in case the reset fails and return 0 anyhow. (Returning an error code, doesn't stop the platform device unregistration and only results in a little helpful error message before the devm cleanup handlers are called.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220725194344.150098-1-u.kleine-koenig@pengutronix.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ACPI: video: Use native backlight on Dell Inspiron N4010Hans de Goede1-0/+8
[ Upstream commit 03c440a26cba6cfa540d65924e9db86fcea362b2 ] The Dell Inspiron N4010 does not have ACPI backlight control, so acpi_video_get_backlight_type()'s heuristics return vendor as the type to use. But the vendor interface is broken, where as the native (intel_backlight) works well, add a quirk to use native. Link: https://lore.kernel.org/regressions/CALF=6jEe5G8+r1Wo0vvz4GjNQQhdkLT5p8uCHn6ZXhg4nsOWow@mail.gmail.com/ Reported-and-tested-by: Ben Greening <bgreening@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17PM: EM: convert power field to micro-Watts precision and align driversLukasz Luba8-43/+100
[ Upstream commit ae6ccaa650380d243cf43d31c864c5ced2fd4612 ] The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen. Update all EM users which access 'power' field and assume the value is in milli-Watts. Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher. Example calculation which shows the rounding error and impact: power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18 power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21 max_freq = 2000MHz cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000 cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203 The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17hwmon: (dell-smm) Add Dell XPS 13 7390 to fan control whitelistArmin Wolf1-0/+8
[ Upstream commit 385e5f57053ff293282fea84c1c27186d53f66e1 ] A user reported that the program dell-bios-fan-control worked on his Dell XPS 13 7390 to switch off automatic fan control. Since it uses the same mechanism as the dell_smm_hwmon module, add this model to the fan control whitelist. Compile-tested only. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Acked-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20220612041806.11367-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17firmware: tegra: Fix error check return value of debugfs_create_file()Lv Ruyi1-5/+5
[ Upstream commit afcdb8e55c91c6ff0700ab272fd0f74e899ab884 ] If an error occurs, debugfs_create_file() will return ERR_PTR(-ERROR), so use IS_ERR() to check it. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: shmobile: rcar-gen2: Increase refcount for new referenceLiang He1-1/+4
[ Upstream commit 75a185fb92e58ccd3670258d8d3b826bd2fa6d29 ] In rcar_gen2_regulator_quirk(), for_each_matching_node_and_match() will automatically increase and decrease the refcount. However, we should call of_node_get() for the new reference created in 'quirk->np'. Besides, we also should call of_node_put() before the 'quirk' being freed. Signed-off-by: Liang He <windhl@126.com> Link: https://lore.kernel.org/r/20220701121804.234223-1-windhl@126.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: dts: allwinner: a64: orangepi-win: Fix LED node nameSamuel Holland1-1/+1
[ Upstream commit b8eb2df19fbf97aa1e950cf491232c2e3bef8357 ] "status" does not match any pattern in the gpio-leds binding. Rename the node to the preferred pattern. This fixes a `make dtbs_check` error. Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220702132816.46456-1-samuel@sholland.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: dts: qcom: ipq8074: fix NAND node nameRobert Marko1-1/+1
[ Upstream commit b39961659ffc3c3a9e3d0d43b0476547b5f35d49 ] Per schema it should be nand-controller@79b0000 instead of nand@79b0000. Fix it to match nand-controller.yaml requirements. Signed-off-by: Robert Marko <robimarko@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220621120642.518575-1-robimarko@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: dts: qcom: add missing AOSS QMP compatible fallbackKrzysztof Kozlowski5-5/+5
[ Upstream commit 6ba93ba9f63fbc44c3a6af7fe6f2536d009cfd5a ] The AOSS QMP bindings expect all compatibles to be followed by fallback "qcom,aoss-qmp" because all of these are actually compatible with each other. This fixes dtbs_check warnings like: sm8250-hdk.dtb: power-controller@c300000: compatible: ['qcom,sm8250-aoss-qmp'] is too short Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220504131923.214367-6-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17arm64: dts: qcom: sc7280: Rename sar sensor labelsGwendal Grignou1-2/+2
[ Upstream commit 9c54f1711fc2516faf1f8d31217462184157b429 ] To ease matching configuration of sysfs attributes for particular sensor, match label reported by iio 'label' attribute with the location label generated by ChromeOS config tool. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220623223119.1858863-1-gwendal@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ARM: dts: qcom: sdx55: Fix the IRQ trigger type for UARTManivannan Sadhasivam1-1/+1
[ Upstream commit ae500b351ab0006d933d804a2b7507fe1e98cecc ] The trigger type should be LEVEL_HIGH. So fix it! Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220530080842.37024-2-manivannan.sadhasivam@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ACPI: LPSS: Fix missing check in register_device_clock()huhai1-0/+3
[ Upstream commit b4f1f61ed5928b1128e60e38d0dffa16966f06dc ] register_device_clock() misses a check for platform_device_register_simple(). Add a check to fix it. Signed-off-by: huhai <huhai@kylinos.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17ACPI: PM: save NVS memory for Lenovo G40-45Manyi Li1-0/+8
[ Upstream commit 4b7ef7b05afcde44142225c184bf43a0cd9e2178 ] [821d6f0359b0614792ab8e2fb93b503e25a65079] is to make machines produced from 2012 to now not saving NVS region to accelerate S3. But, Lenovo G40-45, a platform released in 2015, still needs NVS memory saving during S3. A quirk is introduced for this platform. Signed-off-by: Manyi Li <limanyi@uniontech.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-26 02:52:30 +0300