summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2021-03-18ARM: dts: add silicon_id misc node into aspeed-bmc-intel-ast2600dev-5.8-intelJae Hyun Yoo1-0/+8
This commit adds silicon_id sub-node into misc_control node. Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com> Change-Id: I60c09b654ca8a8881e5df4be07f062280210e570
2021-02-19hwmon: (aspeed-pwm-tacho) Add pwm chip driver supportJae Hyun Yoo1-4/+7
This commit adds pwm chip driver support into aspeed-g6-pwm-tacho driver to enable beep speaker driver. The pwm chip driver cannot be added as a separate platform driver because it makes resource conflicts with existing pwm-tacho driver so it uses hacky tweak on the existing driver. Note: Do not try upstream this hacky implementation. Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com> Change-Id: I22ad12be2ae3a061d7942fec813cdb11be321db7
2021-02-18fixup! ARM: dts: aspeed-bmc-intel-ast2600: Update to latest SGPIOsJason M. Bills1-9/+9
Update based on the latest SGPIO list provided by the Archer City CPLD team. Change-Id: Ia14bcc86171f22b173229d46e1dc2cb9e241ad6f Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
2021-02-04Enable mailbox interruptsYong Li1-3/+3
Support interrupt generation for both 16 and 32 mailbox registers. Tested: After applied this patch, write the mailbox registers from BIOS side, the misc manager can capture the new mailbox data. Change-Id: I4030b6df176a53656aea9cb68ee80b67add8ed14 Signed-off-by: Yong Li <yong.b.li@linux.intel.com>
2021-01-20ARM: dts: aspeed-bmc-intel-ast2600: add status_susack LED nodeJae Hyun Yoo1-0/+5
This commit adds an LED control node for status_susack. Change-Id: I324ac20ec14cecb4c3ff48ec2964a885ad6a4480 Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
2021-01-08fixup! ARM: dts: aspeed-bmc-intel-ast2600: Fix CPU2_MEM_VRHOT nameJason M. Bills1-1/+1
Change-Id: I91a4b82df13c3e1a5ff826e4d893c970e4a1ae02 Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
2021-01-08Update I3C driversDylan Hung2-6/+209
This commit ports I3C updates from Aspeed SDK v00.06.00. Note: Should be refined to get upstreamed. Signed-off-by: Dylan Hung <dylan_hung@aspeedtech.com> Change-Id: Ic674bf5d6b5e72b389c739b136710915aabc6324
2021-01-08ARM: dts: aspeed: enable gpio1 nodeJae Hyun Yoo1-1/+1
This commit enables gpio1 node. Change-Id: I63e8731974190e2241db0bc41e3882f9be37cff4 Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
2020-11-14Revert "Add a WA to defer flash writes on PS_ALERT_N assertion"Jae Hyun Yoo2-10/+1
It's ineffective. A complete solution will be provided in CPLD logic. This reverts commit 40fe787c69a2949684091b4647188d8915c8e2fa. Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com> Change-Id: I0e5972adfd424d64152f208b30add98b67e32d48
2020-11-05Merge v5.8.17, commit '6d07b544ce203a684d9ca52635dcf2f4fc89b7d4' into ↵Jason M. Bills316-1715/+3661
dev-5.8-intel
2020-10-30Merge tag 'v5.8.17' into dev-5.8Joel Stanley92-458/+714
This is the 5.8.17 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-10-29ARM: dts: aspeed-g6: add I3C1 and I3C2 pinctrl settingsJae Hyun Yoo2-0/+14
Pinpad AF22,AF23,AE22 and AE24 are dedicated pins for I3C but pinmux setting should be set in SCU438 register accordingly otherwise I3C pins are not enabled. To fix this issue, this commit adds pinctrl settings for I3C1 and I3C2. Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com> Change-Id: I53818abda31864391de41f8032b38a32e66ec6b4
2020-10-29x86/mce: Make mce_rdmsrl() panic on an inaccessible MSRBorislav Petkov2-12/+70
[ Upstream commit e2def7d49d0812ea40a224161b2001b2e815dce2 ] If an exception needs to be handled while reading an MSR - which is in most of the cases caused by a #GP on a non-existent MSR - then this is most likely the incarnation of a BIOS or a hardware bug. Such bug violates the architectural guarantee that MCA banks are present with all MSRs belonging to them. The proper fix belongs in the hardware/firmware - not in the kernel. Handling an #MC exception which is raised while an NMI is being handled would cause the nasty NMI nesting issue because of the shortcoming of IRET of reenabling NMIs when executed. And the machine is in an #MC context already so <Deity> be at its side. Tracing MSR accesses while in #MC is another no-no due to tracing being inherently a bad idea in atomic context: vmlinux.o: warning: objtool: do_machine_check()+0x4a: call to mce_rdmsrl() leaves .noinstr.text section so remove all that "additional" functionality from mce_rdmsrl() and provide it with a special exception handler which panics the machine when that MSR is not accessible. The exception handler prints a human-readable message explaining what the panic reason is but, what is more, it panics while in the #GP handler and latter won't have executed an IRET, thus opening the NMI nesting issue in the case when the #MC has happened while handling an NMI. (#MC itself won't be reenabled until MCG_STATUS hasn't been cleared). Suggested-by: Andy Lutomirski <luto@kernel.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> [ Add missing prototypes for ex_handler_* ] Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Tony Luck <tony.luck@intel.com> Link: https://lkml.kernel.org/r/20200906212130.GA28456@zn.tnic Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29x86/mce: Annotate mce_rd/wrmsrl() with noinstrBorislav Petkov1-6/+21
[ Upstream commit e100777016fdf6ec3a9d7c1773b15a2b5eca6c55 ] They do get called from the #MC handler which is already marked "noinstr". Commit e2def7d49d08 ("x86/mce: Make mce_rdmsrl() panic on an inaccessible MSR") already got rid of the instrumentation in the MSR accessors, fix the annotation now too, in order to get rid of: vmlinux.o: warning: objtool: do_machine_check()+0x4a: call to mce_rdmsrl() leaves .noinstr.text section Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200915194020.28807-1-bp@alien8.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29x86/mce: Add Skylake quirk for patrol scrub reported errorsBorislav Petkov1-2/+26
[ Upstream commit fd258dc4442c5c1c069c6b5b42bfe7d10cddda95 ] The patrol scrubber in Skylake and Cascade Lake systems can be configured to report uncorrected errors using a special signature in the machine check bank and to signal using CMCI instead of machine check. Update the severity calculation mechanism to allow specifying the model, minimum stepping and range of machine check bank numbers. Add a new rule to detect the special signature (on model 0x55, stepping >=4 in any of the memory controller banks). [ bp: Rewrite it. aegl: Productize it. ] Suggested-by: Youquan Song <youquan.song@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Co-developed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200930021313.31810-2-tony.luck@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29x86/asm: Replace __force_order with a memory clobberArvind Sankar3-24/+17
[ Upstream commit aa5cacdc29d76a005cbbee018a47faa6e724dd2d ] The CRn accessor functions use __force_order as a dummy operand to prevent the compiler from reordering CRn reads/writes with respect to each other. The fact that the asm is volatile should be enough to prevent this: volatile asm statements should be executed in program order. However GCC 4.9.x and 5.x have a bug that might result in reordering. This was fixed in 8.1, 7.3 and 6.5. Versions prior to these, including 5.x and 4.9.x, may reorder volatile asm statements with respect to each other. There are some issues with __force_order as implemented: - It is used only as an input operand for the write functions, and hence doesn't do anything additional to prevent reordering writes. - It allows memory accesses to be cached/reordered across write functions, but CRn writes affect the semantics of memory accesses, so this could be dangerous. - __force_order is not actually defined in the kernel proper, but the LLVM toolchain can in some cases require a definition: LLVM (as well as GCC 4.9) requires it for PIE code, which is why the compressed kernel has a definition, but also the clang integrated assembler may consider the address of __force_order to be significant, resulting in a reference that requires a definition. Fix this by: - Using a memory clobber for the write functions to additionally prevent caching/reordering memory accesses across CRn writes. - Using a dummy input operand with an arbitrary constant address for the read functions, instead of a global variable. This will prevent reads from being reordered across writes, while allowing memory loads to be cached/reordered across CRn reads, which should be safe. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602 Link: https://lore.kernel.org/lkml/20200527135329.1172644-1-arnd@arndb.de/ Link: https://lkml.kernel.org/r/20200902232152.3709896-1-nivedita@alum.mit.edu Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29x86/dumpstack: Fix misleading instruction pointer error messageMark Mossberg1-1/+2
[ Upstream commit 238c91115cd05c71447ea071624a4c9fe661f970 ] Printing "Bad RIP value" if copy_code() fails can be misleading for userspace pointers, since copy_code() can fail if the instruction pointer is valid but the code is paged out. This is because copy_code() calls copy_from_user_nmi() for userspace pointers, which disables page fault handling. This is reproducible in OOM situations, where it's plausible that the code may be reclaimed in the time between entry into the kernel and when this message is printed. This leaves a misleading log in dmesg that suggests instruction pointer corruption has occurred, which may alarm users. Change the message to state the error condition more precisely. [ bp: Massage a bit. ] Signed-off-by: Mark Mossberg <mark.mossberg@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201002042915.403558-1-mark.mossberg@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29KVM: ioapic: break infinite recursion on lazy EOIVitaly Kuznetsov1-4/+1
[ Upstream commit 77377064c3a94911339f13ce113b3abf265e06da ] During shutdown the IOAPIC trigger mode is reset to edge triggered while the vfio-pci INTx is still registered with a resampler. This allows us to get into an infinite loop: ioapic_set_irq -> ioapic_lazy_update_eoi -> kvm_ioapic_update_eoi_one -> kvm_notify_acked_irq -> kvm_notify_acked_gsi -> (via irq_acked fn ptr) irqfd_resampler_ack -> kvm_set_irq -> (via set fn ptr) kvm_set_ioapic_irq -> kvm_ioapic_set_irq -> ioapic_set_irq Commit 8be8f932e3db ("kvm: ioapic: Restrict lazy EOI update to edge-triggered interrupts", 2020-05-04) acknowledges that this recursion loop exists and tries to avoid it at the call to ioapic_lazy_update_eoi, but at this point the scenario is already set, we have an edge interrupt with resampler on the same gsi. Fortunately, the only user of irq ack notifiers (in addition to resamplefd) is i8254 timer interrupt reinjection. These are edge-triggered, so in principle they would need the call to kvm_ioapic_update_eoi_one from ioapic_lazy_update_eoi, but they already disable AVIC(*), so they don't need the lazy EOI behavior. Therefore, remove the call to kvm_ioapic_update_eoi_one from ioapic_lazy_update_eoi. This fixes CVE-2020-27152. Note that this issue cannot happen with SR-IOV assigned devices because virtual functions do not have INTx, only MSI. Fixes: f458d039db7e ("kvm: ioapic: Lazy update IOAPIC EOI") Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29powerpc/pseries: Avoid using addr_to_pfn in real modeGanesh Goudar1-49/+69
[ Upstream commit 4ff753feab021242144818b9a3ba011238218145 ] When an UE or memory error exception is encountered the MCE handler tries to find the pfn using addr_to_pfn() which takes effective address as an argument, later pfn is used to poison the page where memory error occurred, recent rework in this area made addr_to_pfn to run in real mode, which can be fatal as it may try to access memory outside RMO region. Have two helper functions to separate things to be done in real mode and virtual mode without changing any functionality. This also fixes the following error as the use of addr_to_pfn is now moved to virtual mode. Without this change following kernel crash is seen on hitting UE. [ 485.128036] Oops: Kernel access of bad area, sig: 11 [#1] [ 485.128040] LE SMP NR_CPUS=2048 NUMA pSeries [ 485.128047] Modules linked in: [ 485.128067] CPU: 15 PID: 6536 Comm: insmod Kdump: loaded Tainted: G OE 5.7.0 #22 [ 485.128074] NIP: c00000000009b24c LR: c0000000000398d8 CTR: c000000000cd57c0 [ 485.128078] REGS: c000000003f1f970 TRAP: 0300 Tainted: G OE (5.7.0) [ 485.128082] MSR: 8000000000001003 <SF,ME,RI,LE> CR: 28008284 XER: 00000001 [ 485.128088] CFAR: c00000000009b190 DAR: c0000001fab00000 DSISR: 40000000 IRQMASK: 1 [ 485.128088] GPR00: 0000000000000001 c000000003f1fbf0 c000000001634300 0000b0fa01000000 [ 485.128088] GPR04: d000000002220000 0000000000000000 00000000fab00000 0000000000000022 [ 485.128088] GPR08: c0000001fab00000 0000000000000000 c0000001fab00000 c000000003f1fc14 [ 485.128088] GPR12: 0000000000000008 c000000003ff5880 d000000002100008 0000000000000000 [ 485.128088] GPR16: 000000000000ff20 000000000000fff1 000000000000fff2 d0000000021a1100 [ 485.128088] GPR20: d000000002200000 c00000015c893c50 c000000000d49b28 c00000015c893c50 [ 485.128088] GPR24: d0000000021a0d08 c0000000014e5da8 d0000000021a0818 000000000000000a [ 485.128088] GPR28: 0000000000000008 000000000000000a c0000000017e2970 000000000000000a [ 485.128125] NIP [c00000000009b24c] __find_linux_pte+0x11c/0x310 [ 485.128130] LR [c0000000000398d8] addr_to_pfn+0x138/0x170 [ 485.128133] Call Trace: [ 485.128135] Instruction dump: [ 485.128138] 3929ffff 7d4a3378 7c883c36 7d2907b4 794a1564 7d294038 794af082 3900ffff [ 485.128144] 79291f24 790af00e 78e70020 7d095214 <7c69502a> 2fa30000 419e011c 70690040 [ 485.128152] ---[ end trace d34b27e29ae0e340 ]--- Fixes: 9ca766f9891d ("powerpc/64s/pseries: machine check convert to use common event code") Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200724063946.21378-1-ganeshgr@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29powerpc/powernv/dump: Fix race while processing OPAL dumpVasant Hegde1-12/+29
[ Upstream commit 0a43ae3e2beb77e3481d812834d33abe270768ab ] Every dump reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the dump and acknowledges that the dump is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning dump entries when a new sysfs dump entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between dump_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_dump_obj() returns the dump object which if used by caller function will end up in use-after-free problem again. However, the return value of create_dump_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: c7e64b9ce04a ("powerpc/powernv Platform dump interface") Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201017164210.264619-1-hegdevasant@linux.vnet.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: dts: meson8: remove two invalid interrupt lines from the GPU nodeMartin Blumenstingl1-2/+0
[ Upstream commit 737e7610b545cc901a9696083c1824a7104b8d1b ] The 3.10 vendor kernel defines the following GPU 20 interrupt lines: #define INT_MALI_GP AM_IRQ(160) #define INT_MALI_GP_MMU AM_IRQ(161) #define INT_MALI_PP AM_IRQ(162) #define INT_MALI_PMU AM_IRQ(163) #define INT_MALI_PP0 AM_IRQ(164) #define INT_MALI_PP0_MMU AM_IRQ(165) #define INT_MALI_PP1 AM_IRQ(166) #define INT_MALI_PP1_MMU AM_IRQ(167) #define INT_MALI_PP2 AM_IRQ(168) #define INT_MALI_PP2_MMU AM_IRQ(169) #define INT_MALI_PP3 AM_IRQ(170) #define INT_MALI_PP3_MMU AM_IRQ(171) #define INT_MALI_PP4 AM_IRQ(172) #define INT_MALI_PP4_MMU AM_IRQ(173) #define INT_MALI_PP5 AM_IRQ(174) #define INT_MALI_PP5_MMU AM_IRQ(175) #define INT_MALI_PP6 AM_IRQ(176) #define INT_MALI_PP6_MMU AM_IRQ(177) #define INT_MALI_PP7 AM_IRQ(178) #define INT_MALI_PP7_MMU AM_IRQ(179) However, the driver from the 3.10 vendor kernel does not use the following four interrupt lines: - INT_MALI_PP3 - INT_MALI_PP3_MMU - INT_MALI_PP7 - INT_MALI_PP7_MMU Drop the "pp3" and "ppmmu3" interrupt lines. This is also important because there is no matching entry in interrupt-names for it (meaning the "pp2" interrupt is actually assigned to the "pp3" interrupt line). Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU") Reported-by: Thomas Graichen <thomas.graichen@gmail.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Tested-by: thomas graichen <thomas.graichen@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200815181957.408649-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: zynqmp: Remove additional compatible string for i2c IPsMichal Simek1-2/+2
[ Upstream commit 35292518cb0a626fcdcabf739aed75060a018ab5 ] DT binding permits only one compatible string which was decribed in past by commit 63cab195bf49 ("i2c: removed work arounds in i2c driver for Zynq Ultrascale+ MPSoC"). The commit aea37006e183 ("dt-bindings: i2c: cadence: Migrate i2c-cadence documentation to YAML") has converted binding to yaml and the following issues is reported: ...: i2c@ff030000: compatible: Additional items are not allowed ('cdns,i2c-r1p10' was unexpected) From schema: .../Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml fds ...: i2c@ff030000: compatible: ['cdns,i2c-r1p14', 'cdns,i2c-r1p10'] is too long The commit c415f9e8304a ("ARM64: zynqmp: Fix i2c node's compatible string") has added the second compatible string but without removing origin one. The patch is only keeping one compatible string "cdns,i2c-r1p14". Fixes: c415f9e8304a ("ARM64: zynqmp: Fix i2c node's compatible string") Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/cc294ae1a79ef845af6809ddb4049f0c0f5bb87a.1598259551.git.michal.simek@xilinx.com Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: dts: iwg20d-q7-common: Fix touch controller probe failureBiju Das1-1/+14
[ Upstream commit 08d7a73fffb6769b1cf2278bf697e692daba3abf ] As per the iWave RZ/G1M schematic, the signal LVDS_PPEN controls the supply voltage for the touch panel, LVDS receiver and RGB LCD panel. Add a regulator for these device nodes and remove the powerdown-gpios property from the lvds-receiver node as it results in a touch controller driver probe failure. Fixes: 6f89dd9e9325 ("ARM: dts: iwg20d-q7-common: Add LCD support") Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20200924080535.3641-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: dts: stm32: Fix DH PDK2 display PWM channelMarek Vasut1-1/+1
[ Upstream commit 57592d2a98dbc3bde3ddc062e91a8486bdcb211e ] The display PWM channel is number 3 (PWM2 CH4), make it so. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: dts: stm32: Swap PHY reset GPIO and TSC2004 IRQ on DHCOM SOMMarek Vasut1-2/+2
[ Upstream commit 9ad98319e95263469d8ca2cb543c37c5a2f40980 ] On the production revision of the SoM, 587-200, the PHY reset GPIO and touchscreen IRQs are swapped to prevent collision between EXTi IRQs, reflect that in DT. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: dts: stm32: Move ethernet PHY into DH SoM DTMarek Vasut2-33/+36
[ Upstream commit b0a07f609600b6fa4c30f783db50c38456804485 ] The PHY and the VIO regulator is populated on the SoM, move it into the SoM DT. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: dts: stm32: lxa-mc1: Fix kernel warning about PHY delaysHolger Assmann1-2/+0
[ Upstream commit 42a31ac6698681363363d48335559d212a26a7ca ] The KSZ9031 PHY skew timings for rxc/txc, originally set to achieve the desired phase shift between clock- and data-signal, now trigger a kernel warning when used in rgmii-id mode: *-skew-ps values should be used only with phy-mode = "rgmii" This is because commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") now configures own timings when phy-mode = "rgmii-id". Device trees wanting to set their own delays should use phy-mode "rgmii" instead as the warning prescribes. The "standard" timings now used with "rgmii-id" work fine on this board, so drop the explicit timings in the device tree and thereby silence the warning. Fixes: 666b5ca85cd3 ("ARM: dts: stm32: add STM32MP1-based Linux Automation MC-1 board") Signed-off-by: Holger Assmann <h.assmann@pengutronix.de> Acked-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: dts: stm32: Fix sdmmc2 pins on AV96Marek Vasut1-3/+3
[ Upstream commit 1ad6e36ec266cedb0d274aa13253ff1fb2eed4ba ] The AV96 uses sdmmc2_d47_pins_c and sdmmc2_d47_sleep_pins_c, which differ from sdmmc2_d47_pins_b and sdmmc2_d47_sleep_pins_b in one pin, SDMMC2_D5, which is PA15 in the former and PA9 in the later. The PA15 is correct on AV96, so fix this. This error is likely a result of rebasing across the stm32mp1 DT pinctrl rework. Fixes: 611325f68102 ("ARM: dts: stm32: Add eMMC attached to SDMMC2 on AV96") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: OMAP2+: Restore MPU power domain if cpu_cluster_pm_enter() failsTony Lindgren1-1/+3
[ Upstream commit 8f04aea048d56f3e39a7e543939450246542a6fc ] If cpu_cluster_pm_enter() fails, we need to set MPU power domain back to enabled to prevent the next WFI from potentially triggering an undesired MPU power domain state change. We already do this for omap_enter_idle_smp() but are missing it for omap_enter_idle_coupled(). Fixes: 55be2f50336f ("ARM: OMAP2+: Handle errors for cpu_pm") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: dts: owl-s500: Fix incorrect PPI interrupt specifiersCristian Ciocaltea1-3/+3
[ Upstream commit 55f6c9931f7c32f19cf221211f099dfd8dab3af9 ] The PPI interrupts for cortex-a9 were incorrectly specified, fix them. Fixes: fdfe7f4f9d85 ("ARM: dts: Add Actions Semi S500 and LeMaker Guitar") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com> Reviewed-by: Peter Korsgaard <peter@korsgaard.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: actions: limit address range for pinctrl nodeAmit Singh Tomar1-1/+1
[ Upstream commit 4bb1eb3cd4bd6241d5e5f99bbfd801ea5a007b6c ] After commit 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for Actions Semi S700") following error has been observed while booting Linux on Cubieboard7-lite(based on S700 SoC). [ 0.257415] pinctrl-s700 e01b0000.pinctrl: can't request region for resource [mem 0xe01b0000-0xe01b0fff] [ 0.266902] pinctrl-s700: probe of e01b0000.pinctrl failed with error -16 This is due to the fact that memory range for "sps" power domain controller clashes with pinctrl. One way to fix it, is to limit pinctrl address range which is safe to do as current pinctrl driver uses address range only up to 0x100. This commit limits the pinctrl address range to 0x100 so that it doesn't conflict with sps range. Fixes: 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for Actions Semi S700") Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Suggested-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: mt8173: elm: Fix nor_flash node propertyHsin-Yi Wang1-3/+2
[ Upstream commit 1276be23fd53e1c4e752966d0eab42aa54a343da ] bus-width and non-removable is not used by the driver. max-frequency should be spi-max-frequency for flash node. Fixes: 689b937bedde ("arm64: dts: mediatek: add mt8173 elm and hana board") Reported-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20200727074124.3779237-1-hsinyi@chromium.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: renesas: r8a774c0: Fix MSIOF1 DMA channelsGeert Uytterhoeven1-3/+2
[ Upstream commit c91dfc9818df5f43c10c727f1cecaebdb5e2fa92 ] According to Technical Update TN-RCT-S0352A/E, MSIOF1 DMA can only be used with SYS-DMAC0 on R-Car E3. Fixes: 62c0056f1c3eb15d ("arm64: dts: renesas: r8a774c0: Add MSIOF nodes") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200917132117.8515-3-geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: renesas: r8a77990: Fix MSIOF1 DMA channelsGeert Uytterhoeven1-3/+2
[ Upstream commit 453802c463abd003a7c38ffbc90b67ba162335b6 ] According to Technical Update TN-RCT-S0352A/E, MSIOF1 DMA can only be used with SYS-DMAC0 on R-Car E3. Fixes: 8517042060b55a37 ("arm64: dts: renesas: r8a77990: Add DMA properties to MSIOF nodes") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200917132117.8515-2-geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: qcom: msm8916: Fix MDP/DSI interruptsStephan Gerhold1-2/+2
[ Upstream commit 027cca9eb5b450c3f6bb916ba999144c2ec23cb7 ] The mdss node sets #interrupt-cells = <1>, so its interrupts should be referenced using a single cell (in this case: only the interrupt number). However, right now the mdp/dsi node both have two interrupt cells set, e.g. interrupts = <4 0>. The 0 is probably meant to say IRQ_TYPE_NONE (= 0), but with #interrupt-cells = <1> this is actually interpreted as a second interrupt line. Remove the IRQ flags from both interrupts to fix this. Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200915071221.72895-5-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: qcom: pm8916: Remove invalid reg size from wcd_codecStephan Gerhold1-1/+1
[ Upstream commit c2f0cbb57dbac6da3d38b47b5b96de0fe4e23884 ] Tha parent node of "wcd_codec" specifies #address-cells = <1> and #size-cells = <0>, which means that each resource should be described by one cell for the address and size omitted. However, wcd_codec currently lists 0x200 as second cell (probably the size of the resource). When parsing this would be treated like another memory resource - which is entirely wrong. To quote the device tree specification [1]: "If the parent node specifies a value of 0 for #size-cells, the length field in the value of reg shall be omitted." [1]: https://www.devicetree.org/specifications/ Fixes: 5582fcb3829f ("arm64: dts: apq8016-sbc: add analog audio support with multicodec") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200915071221.72895-4-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: qcom: msm8916: Remove one more thermal trip point unit nameStephan Gerhold1-3/+3
[ Upstream commit e6859ae8603c5946b8f3ecbd9b4f02b72955b9d0 ] Commit fe2aff0c574d2 ("arm64: dts: qcom: msm8916: remove unit name for thermal trip points") removed the unit names for most of the thermal trip points defined in msm8916.dtsi, but missed to update the one for cpu0_1-thermal. So why wasn't this spotted by "make dtbs_check"? Apparently, the name of the thermal zone is already invalid: thermal-zones.yaml specifies a regex of ^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$, so it is not allowed to contain underscores. Therefore the thermal zone was never verified using the DTB schema. After replacing the underscore in the thermal zone name, the warning shows up: apq8016-sbc.dt.yaml: thermal-zones: cpu0-1-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' Fix up the thermal zone names and remove the unit name for the trip point. Cc: Amit Kucheria <amit.kucheria@linaro.org> Fixes: fe2aff0c574d2 ("arm64: dts: qcom: msm8916: remove unit name for thermal trip points") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200915071221.72895-3-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: qcom: sc7180: Drop flags on mdss irqsStephen Boyd1-2/+2
[ Upstream commit 51e9874d382e089f664b3ce12773bbbaece5f369 ] The number of interrupt cells for the mdss interrupt controller is 1, meaning there should only be one cell for the interrupt number, not two where the second cell is the irq flags. Drop the second cell to match the binding. Cc: Kalyan Thota <kalyan_t@codeaurora.org> Cc: Harigovindan P <harigovi@codeaurora.org Fixes: a3db7ad1af49 ("arm64: dts: sc7180: add display dt nodes") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200811192503.1811462-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: imx8mq: Add missing interrupts to GPCKrzysztof Kozlowski1-0/+1
[ Upstream commit 791619f66843a213784efb2f171be98933bad991 ] The i.MX General Power Controller v2 device node was missing interrupts property necessary to route its interrupt to GIC. This also fixes the dbts_check warnings like: arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpc@303a0000: {'compatible': ... '$nodename': ['gpc@303a0000']} is not valid under any of the given schemas arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpc@303a0000: 'interrupts' is a required property Fixes: fdbcc04da246 ("arm64: dts: imx8mq: add GPC power domains") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: qcom: sc7180: Fix the LLCC base register sizeSai Prakash Ranjan1-1/+1
[ Upstream commit efe788361f72914017515223414d3f20abe4b403 ] There is one LLCC logical bank(LLCC0) on SC7180 SoC and the size of the LLCC0 base is 0x50000(320KB) not 2MB, so correct the size and fix copy paste mistake carried over from SDM845. Reviewed-by: Douglas Anderson <dianders@chromium.org> Fixes: 7cee5c742899 ("arm64: dts: qcom: sc7180: Fix node order") Fixes: c831fa299996 ("arm64: dts: qcom: sc7180: Add Last level cache controller node") Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Link: https://lore.kernel.org/r/20200818145514.16262-1-saiprakash.ranjan@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: allwinner: h5: remove Mali GPU PMU moduleQiang Yu1-4/+2
[ Upstream commit 2933bf3528007f834fb7f5eab033f9c5b0683f91 ] H5's Mali GPU PMU is not present or working corretly although H5 datasheet record its interrupt vector. Adding this module will miss lead lima driver try to shutdown it and get waiting timeout. This problem is not exposed before lima runtime PM support is added. Fixes: bb39ed07e55b ("arm64: dts: allwinner: h5: Add device node for Mali-450 GPU") Signed-off-by: Qiang Yu <yuq825@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20200822062755.534761-1-yuq825@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: dts: sun8i: r40: bananapi-m2-ultra: Fix dcdc1 regulatorJernej Skrabec1-5/+5
[ Upstream commit 3658a2b7f3e16c7053eb8d70657b94bb62c5a0f4 ] DCDC1 regulator powers many different subsystems. While some of them can work at 3.0 V, some of them can not. For example, VCC-HDMI can only work between 3.24 V and 3.36 V. According to OS images provided by the board manufacturer this regulator should be set to 3.3 V. Set DCDC1 and DCDC1SW to 3.3 V in order to fix this. Fixes: da7ac948fa93 ("ARM: dts: sun8i: Add board dts file for Banana Pi M2 Ultra") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20200824193649.978197-1-jernej.skrabec@siol.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: s3c24xx: fix mmc gpio lookup tablesArnd Bergmann5-9/+9
[ Upstream commit 3af4e8774b6d03683932b0961998e01355bccd74 ] The gpio controller names differ between s3c24xx and s3c64xx, and it seems that these all got the wrong names, using GPx instead of GPIOx. Fixes: d2951dfa070d ("mmc: s3cmci: Use the slot GPIO descriptor") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200806182059.2431-3-krzk@kernel.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: at91: pm: of_node_put() after its usageClaudiu Beznea1-0/+1
[ Upstream commit e222f943519564978e082c152b4140a47e93392c ] Put node after it has been used. Fixes: 13f16017d3e3f ("ARM: at91: pm: Tie the USB clock mask to the pmc") Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/1596616610-15460-4-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ARM: dts: imx6sl: fix rng nodeHoria Geantă1-0/+2
[ Upstream commit 82ffb35c2ce63ef8e0325f75eb48022abcf8edbe ] rng DT node was added without a compatible string. i.MX driver for RNGC (drivers/char/hw_random/imx-rngc.c) also claims support for RNGB, and is currently used for i.MX25. Let's use this driver also for RNGB block in i.MX6SL. Fixes: e29fe21cff96 ("ARM: dts: add device tree source for imx6sl SoC") Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: dts: meson: vim3: correct led polarityJerome Brunet1-2/+2
[ Upstream commit 1f9d87d08e4a2299e86f8a1600aedf87ecd3b636 ] The LEDs on the vim3 are active when the gpio is high, not low. Fixes: c6d29c66e582 ("arm64: dts: meson-g12b-khadas-vim3: add initial device-tree") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200803141850.172704-1-jbrunet@baylibre.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29arm64: mm: use single quantity to represent the PA to VA translationArd Biesheuvel3-25/+14
[ Upstream commit 7bc1a0f9e1765830e945669c99c59c35cf9bca82 ] On arm64, the global variable memstart_addr represents the physical address of PAGE_OFFSET, and so physical to virtual translations or vice versa used to come down to simple additions or subtractions involving the values of PAGE_OFFSET and memstart_addr. When support for 52-bit virtual addressing was introduced, we had to deal with PAGE_OFFSET potentially being outside of the region that can be covered by the virtual range (as the 52-bit VA capable build needs to be able to run on systems that are only 48-bit VA capable), and for this reason, another translation was introduced, and recorded in the global variable physvirt_offset. However, if we go back to the original definition of memstart_addr, i.e., the physical address of PAGE_OFFSET, it turns out that there is no need for two separate translations: instead, we can simply subtract the size of the unaddressable VA space from memstart_addr to make the available physical memory appear in the 48-bit addressable VA region. This simplifies things, but also fixes a bug on KASLR builds, which may update memstart_addr later on in arm64_memblock_init(), but fails to update vmemmap and physvirt_offset accordingly. Fixes: 5383cc6efed1 ("arm64: mm: Introduce vabits_actual") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Steve Capper <steve.capper@arm.com> Link: https://lore.kernel.org/r/20201008153602.9467-2-ardb@kernel.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29KVM: x86: emulating RDPID failure shall return #UD rather than #GPRobert Hoo1-1/+1
[ Upstream commit a9e2e0ae686094571378c72d8146b5a1a92d0652 ] Per Intel's SDM, RDPID takes a #UD if it is unsupported, which is more or less what KVM is emulating when MSR_TSC_AUX is not available. In fact, there are no scenarios in which RDPID is supposed to #GP. Fixes: fb6d4d340e ("KVM: x86: emulate RDPID") Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Message-Id: <1598581422-76264-1-git-send-email-robert.hu@linux.intel.com> Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29s390/pci: Mark all VFs as not implementing PCI_COMMAND_MEMORYMatthew Rosato1-2/+3
[ Upstream commit 08b6e22b850c28b6032da1e4d767a33116e23dfb ] For s390 we can have VFs that are passed-through without the associated PF. Firmware provides an emulation layer to allow these devices to operate independently, but is missing emulation of the Memory Space Enable bit. For these as well as linked VFs, set no_command_memory which specifies these devices do not implement PCI_COMMAND_MEMORY. Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29um: time-travel: Fix IRQ handling in time_travel_handle_message()Johannes Berg1-5/+9
[ Upstream commit ebef8ea2ba967026192a26f4529890893919bc57 ] As the comment here indicates, we need to do the polling in the idle loop without blocking interrupts, since interrupts can be vhost-user messages that we must process even while in our idle loop. I don't know why I explained one thing and implemented another, but we have indeed observed random hangs due to this, depending on the timing of the messages. Fixes: 88ce64249233 ("um: Implement time-travel=ext") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-13 02:40:42 +0300