| Age | Commit message (Collapse) | Author |
|---|
|
An L0 must invalidate the L2's RPT during H_GUEST_DELETE if this has not
already been done. This is a slow operation that means H_GUEST_DELETE
must return H_BUSY multiple times before completing. Invalidating the
tables before deleting the guest so there is less work for the L0 to do.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231201132618.555031-2-vaibhav@linux.ibm.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc fix from Helge Deller:
"A single line patch for parisc which fixes the build in tinyconfig
configurations:
- Fix asm operand number out of range build error in bug table"
* tag 'parisc-for-6.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Fix asm operand number out of range build error in bug table
|
|
There are three major changes here:
1. Add arch_[alloc|free]_bpf_trampoline based on bpf_prog_pack;
2. Let arch_prepare_bpf_trampoline handle ROX input image, this requires
arch_prepare_bpf_trampoline allocating a temporary RW buffer;
3. Update __arch_prepare_bpf_trampoline() to handle a RW buffer (rw_image)
and a ROX buffer (image). This part is similar to the image/rw_image
logic in bpf_int_jit_compile().
Signed-off-by: Song Liu <song@kernel.org>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20231206224054.492250-8-song@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Instead of blindly allocating PAGE_SIZE for each trampoline, check the size
of the trampoline with arch_bpf_trampoline_size(). This size is saved in
bpf_tramp_image->size, and used for modmem charge/uncharge. The fallback
arch_alloc_bpf_trampoline() still allocates a whole page because we need to
use set_memory_* to protect the memory.
struct_ops trampoline still uses a whole page for multiple trampolines.
With this size check at caller (regular trampoline and struct_ops
trampoline), remove arch_bpf_trampoline_size() from
arch_prepare_bpf_trampoline() in archs.
Also, update bpf_image_ksym_add() to handle symbol of different sizes.
Signed-off-by: Song Liu <song@kernel.org>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Tested-by: Ilya Leoshkevich <iii@linux.ibm.com> # on s390x
Acked-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Björn Töpel <bjorn@rivosinc.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com> # on riscv
Link: https://lore.kernel.org/r/20231206224054.492250-7-song@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
This helper will be used to calculate the size of the trampoline before
allocating the memory.
arch_prepare_bpf_trampoline() for arm64 and riscv64 can use
arch_bpf_trampoline_size() to check the trampoline fits in the image.
OTOH, arch_prepare_bpf_trampoline() for s390 has to call the JIT process
twice, so it cannot use arch_bpf_trampoline_size().
Signed-off-by: Song Liu <song@kernel.org>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Tested-by: Ilya Leoshkevich <iii@linux.ibm.com> # on s390x
Acked-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Björn Töpel <bjorn@rivosinc.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com> # on riscv
Link: https://lore.kernel.org/r/20231206224054.492250-6-song@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
x86's implementation of arch_prepare_bpf_trampoline() requires
BPF_INSN_SAFETY buffer space between end of program and image_end. OTOH,
the return value does not include BPF_INSN_SAFETY. This doesn't cause any
real issue at the moment. However, "image" of size retval is not enough for
arch_prepare_bpf_trampoline(). This will cause confusion when we introduce
a new helper arch_bpf_trampoline_size(). To avoid future confusion, adjust
the return value to include BPF_INSN_SAFETY.
Signed-off-by: Song Liu <song@kernel.org>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20231206224054.492250-5-song@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
We are using "im" for "struct bpf_tramp_image" and "tr" for "struct
bpf_trampoline" in most of the code base. The only exception is the
prototype and fallback version of arch_prepare_bpf_trampoline(). Update
them to match the rest of the code base.
We mix "orig_call" and "func_addr" for the argument in different versions
of arch_prepare_bpf_trampoline(). s/orig_call/func_addr/g so they match.
Signed-off-by: Song Liu <song@kernel.org>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Tested-by: Ilya Leoshkevich <iii@linux.ibm.com> # on s390x
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20231206224054.492250-3-song@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
|
|
Ignat Korchagin complained that a potential config regression was
introduced by commit 89cde455915f ("kexec: consolidate kexec and crash
options into kernel/Kconfig.kexec"). Before the commit, CONFIG_CRASH_DUMP
has no dependency on CONFIG_KEXEC. After the commit, CRASH_DUMP selects
KEXEC. That enforces system to have CONFIG_KEXEC=y as long as
CONFIG_CRASH_DUMP=Y which people may not want.
In Ignat's case, he sets CONFIG_CRASH_DUMP=y, CONFIG_KEXEC_FILE=y and
CONFIG_KEXEC=n because kexec_load interface could have security issue if
kernel/initrd has no chance to be signed and verified.
CRASH_DUMP has select of KEXEC because Eric, author of above commit, met a
LKP report of build failure when posting patch of earlier version. Please
see below link to get detail of the LKP report:
https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b988e@oracle.com/T/#u
In fact, that LKP report is triggered because arm's <asm/kexec.h> is
wrapped in CONFIG_KEXEC ifdeffery scope. That is wrong. CONFIG_KEXEC
controls the enabling/disabling of kexec_load interface, but not kexec
feature. Removing the wrongly added CONFIG_KEXEC ifdeffery scope in
<asm/kexec.h> of arm allows us to drop the select KEXEC for CRASH_DUMP.
Meanwhile, change arch/arm/kernel/Makefile to let machine_kexec.o
relocate_kernel.o depend on KEXEC_CORE.
Link: https://lkml.kernel.org/r/20231128054457.659452-1-bhe@redhat.com
Fixes: 89cde455915f ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec")
Signed-off-by: Baoquan He <bhe@redhat.com>
Reported-by: Ignat Korchagin <ignat@cloudflare.com>
Tested-by: Ignat Korchagin <ignat@cloudflare.com> [compile-time only]
Tested-by: Alexander Gordeev <agordeev@linux.ibm.com>
Reviewed-by: Eric DeVolder <eric_devolder@yahoo.com>
Tested-by: Eric DeVolder <eric_devolder@yahoo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Lee pointed out issue found by syscaller [0] hitting BUG in prog array
map poke update in prog_array_map_poke_run function due to error value
returned from bpf_arch_text_poke function.
There's race window where bpf_arch_text_poke can fail due to missing
bpf program kallsym symbols, which is accounted for with check for
-EINVAL in that BUG_ON call.
The problem is that in such case we won't update the tail call jump
and cause imbalance for the next tail call update check which will
fail with -EBUSY in bpf_arch_text_poke.
I'm hitting following race during the program load:
CPU 0 CPU 1
bpf_prog_load
bpf_check
do_misc_fixups
prog_array_map_poke_track
map_update_elem
bpf_fd_array_map_update_elem
prog_array_map_poke_run
bpf_arch_text_poke returns -EINVAL
bpf_prog_kallsyms_add
After bpf_arch_text_poke (CPU 1) fails to update the tail call jump, the next
poke update fails on expected jump instruction check in bpf_arch_text_poke
with -EBUSY and triggers the BUG_ON in prog_array_map_poke_run.
Similar race exists on the program unload.
Fixing this by moving the update to bpf_arch_poke_desc_update function which
makes sure we call __bpf_arch_text_poke that skips the bpf address check.
Each architecture has slightly different approach wrt looking up bpf address
in bpf_arch_text_poke, so instead of splitting the function or adding new
'checkip' argument in previous version, it seems best to move the whole
map_poke_run update as arch specific code.
[0] https://syzkaller.appspot.com/bug?extid=97a4fe20470e9bc30810
Fixes: ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT")
Reported-by: syzbot+97a4fe20470e9bc30810@syzkaller.appspotmail.com
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Cc: Lee Jones <lee@kernel.org>
Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/bpf/20231206083041.1306660-2-jolsa@kernel.org
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt
Renesas DTS updates for v6.8
- Add FLASH support for the Renesas Marzen and Blanche development
boards,
- Add 4-bit TX support for the QSPI FLASHes on the RZ/G2L, RZ/G2LC,
and RZ/V2L SMARC SoMs,
- Add SDHI support for the RZ/G3S SMARC development kit,
- Add LCD support for the Atmark Techno Armadillo-800-EVA development
board, which requires switching from the legacy frame buffer device
driver to the DRM driver,
- Miscellaneous fixes and improvements.
* tag 'renesas-dts-for-v6.8-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
ARM: dts: renesas: r9a06g032: Add missing space in compatible
arm64: dts: renesas: r9a09g011: Add missing space in compatible
ARM: dts: renesas: armadillo800eva: Add LCD panel
ARM: dts: renesas: r8a7740: Add LCDC nodes
ARM: shmobile: defconfig: Switch to DRM_SHMOBILE
arm64: dts: renesas: draak: Move HDMI bus properties to correct node
arm64: dts: renesas: draak: Make HDMI the default video input
arm64: dts: renesas: rzg3s-smarc: Enable SDHI1
arm64: dts: renesas: rzg3s-smarc-som: Enable SDHI2
arm64: dts: renesas: rzg2lc-smarc-som: Enable 4-bit tx support
arm64: dts: renesas: rzg2l-smarc-som: Enable 4-bit tx support
ARM: dts: renesas: marzen: Rename keyboard nodes
ARM: dts: renesas: iwg22d-sodimm: Fix stmpe node names
arm64: dts: renesas: Add missing ADV751[13] power supply properties
ARM: dts: renesas: Add missing ADV751[13] power supply properties
ARM: dts: renesas: rcar-gen2: Fix I2C bus demux node names
riscv: dts: renesas: Convert isa detection to new properties
ARM: dts: renesas: blanche: Add FLASH node
ARM: dts: renesas: marzen: Add FLASH node
Link: https://lore.kernel.org/r/cover.1701433489.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Add Toradex Verdin AM62 Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.
https://www.toradex.com/products/carrier-board/mallow-carrier-board
Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20231205184605.35225-4-francesco@dolcini.it
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/defconfig
Renesas ARM defconfig updates for v6.8
- Enable support for the Renesas VersaClock 3 clock generator in the
arm64 defconfig,
- Enable support for the Renesas EtherAVB module in the arm multi_v7
defconfig,
- Refresh shmobile_defconfig for v6.7-rc1.
* tag 'renesas-arm-defconfig-for-v6.8-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
ARM: shmobile: defconfig: Refresh for v6.7-rc1
ARM: multi_v7_defconfig: Enable CONFIG_RAVB
arm64: defconfig: Enable Renesas VersaClock 3 clock generator config
Link: https://lore.kernel.org/r/cover.1701433487.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
SCMI reset controllers are used in the ARMv7 STMicroelectronics stm32mp
boards:
- for STM32MP13: stm32mp135f-dk
- for STM32MP15 boards with SCMI variant, introduced by commit 5b7e58313a77
("ARM: dts: stm32: Add SCMI version of STM32 boards (DK1/DK2/ED1/EV1)")
* stm32mp157c-ev1-scmi
* stm32mp157c-ed1-scmi
* stm32mp157c-dk2-scmi
* stm32mp157a-dk1-scmi
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Signed-off-by: Etienne Carriere <etienne.carriere@foss.st.com>
Link: https://lore.kernel.org/r/20231103085400.2924282-1-etienne.carriere@foss.st.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://github.com/Broadcom/stblinux into arm/fixes
This pull request contains Broadcom ARM-based SoCs Device Tree fixes for
6.7, please pull the following:
- Stefan corrects the disabling of the activity LED for the Raspberry Pi
400
* tag 'arm-soc/for-6.7/devicetree-fixes' of https://github.com/Broadcom/stblinux:
ARM: dts: bcm2711-rpi-400: Fix delete-node of led_act
Link: https://lore.kernel.org/r/20231205225021.653045-1-florian.fainelli@broadcom.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes
RISC-V Devicetree fixes for v6.7-rc4
Two fixes, both rather minor. The first fixes some dtbs_check warnings
introduced after an update to the bindings, that returns the
architecture to being clean of dtbs_check issues. The second relocates
a soc-specific property to the appropriate location in $soc.dtsi, and
hopefully avoids the same mistake being copy-pasted into more
devicetrees.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
* tag 'riscv-dt-fixes-for-v6.7-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
riscv: dts: microchip: move timebase-frequency to mpfs.dtsi
riscv: dts: sophgo: remove address-cells from intc node
Link: https://lore.kernel.org/r/20231130-maternity-majestic-dd29f0170050@spud
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into arm/fixes
MediaTek ARM64 DeviceTree fixes for v6.7
Fixes for various MediaTek SoCs, including
MT7986: - eMMC HS400 mode failures
- Cooling trips for emergency system shutdown
- BPI-R3 machine SFP power limit and active cooling
MT8173: - EVB device tree unit_address_vs_reg warning
MT8183: - unit_address_vs_reg and simple_bus_reg warnings
- Kukui device tree nodes naming consistency and
adhering to bindings
- Jacuzzi device tree unnecessary cells removed as
those were producing avoid_unnecessary_addr_size
MT8186: - Power domains faults due to incorrect clocks
- GPU speed bin nvmem cell name was wrong, producing
issues with interpreting the speedbin with GPU OPPs
MT8195: - Local Arbiter (and whole system) ability to suspend
- Cherry device tree interrupts_property warning
...and another unit_address_vs_reg warning on MT7622.
* tag 'mtk-dts64-fixes-for-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
arm64: dts: mediatek: cherry: Fix interrupt cells for MT6360 on I2C7
arm64: dts: mediatek: mt8183-kukui-jacuzzi: fix dsi unnecessary cells properties
arm64: dts: mediatek: mt7622: fix memory node warning check
arm64: dts: mediatek: mt8186: fix clock names for power domains
arm64: dts: mediatek: mt8186: Change gpu speedbin nvmem cell name
arm64: dts: mt7986: change cooling trips
arm64: dts: mt7986: define 3W max power to both SFP on BPI-R3
arm64: dts: mt7986: fix emmc hs400 mode without uboot initialization
arm64: dts: mt8183: kukui: Fix underscores in node names
arm64: dts: mediatek: mt8183: Move thermal-zones to the root node
arm64: dts: mediatek: mt8173-evb: Fix regulator-fixed node names
arm64: dts: mediatek: mt8183-evb: Fix unit_address_vs_reg warning on ntc
arm64: dts: mediatek: mt8183: Fix unit address for scp reserved memory
arm64: dts: mediatek: mt8195: Fix PM suspend/resume with venc clocks
Link: https://lore.kernel.org/r/20231129113905.134732-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
We need to probe for IOCP only once during boot stage, as we were probing
for IOCP for all the stages this caused the below issue during module-init
stage,
[9.019104] Unable to handle kernel paging request at virtual address ffffffff8100d3a0
[9.027153] Oops [#1]
[9.029421] Modules linked in: rcar_canfd renesas_usbhs i2c_riic can_dev spi_rspi i2c_core
[9.037686] CPU: 0 PID: 90 Comm: udevd Not tainted 6.7.0-rc1+ #57
[9.043756] Hardware name: Renesas SMARC EVK based on r9a07g043f01 (DT)
[9.050339] epc : riscv_noncoherent_supported+0x10/0x3e
[9.055558] ra : andes_errata_patch_func+0x4a/0x52
[9.060418] epc : ffffffff8000d8c2 ra : ffffffff8000d95c sp : ffffffc8003abb00
[9.067607] gp : ffffffff814e25a0 tp : ffffffd80361e540 t0 : 0000000000000000
[9.074795] t1 : 000000000900031e t2 : 0000000000000001 s0 : ffffffc8003abb20
[9.081984] s1 : ffffffff015b57c7 a0 : 0000000000000000 a1 : 0000000000000001
[9.089172] a2 : 0000000000000000 a3 : 0000000000000000 a4 : ffffffff8100d8be
[9.096360] a5 : 0000000000000001 a6 : 0000000000000001 a7 : 000000000900031e
[9.103548] s2 : ffffffff015b57d7 s3 : 0000000000000001 s4 : 000000000000031e
[9.110736] s5 : 8000000000008a45 s6 : 0000000000000500 s7 : 000000000000003f
[9.117924] s8 : ffffffc8003abd48 s9 : ffffffff015b1140 s10: ffffffff8151a1b0
[9.125113] s11: ffffffff015b1000 t3 : 0000000000000001 t4 : fefefefefefefeff
[9.132301] t5 : ffffffff015b57c7 t6 : ffffffd8b63a6000
[9.137587] status: 0000000200000120 badaddr: ffffffff8100d3a0 cause: 000000000000000f
[9.145468] [<ffffffff8000d8c2>] riscv_noncoherent_supported+0x10/0x3e
[9.151972] [<ffffffff800027e8>] _apply_alternatives+0x84/0x86
[9.157784] [<ffffffff800029be>] apply_module_alternatives+0x10/0x1a
[9.164113] [<ffffffff80008fcc>] module_finalize+0x5e/0x7a
[9.169583] [<ffffffff80085cd6>] load_module+0xfd8/0x179c
[9.174965] [<ffffffff80086630>] init_module_from_file+0x76/0xaa
[9.180948] [<ffffffff800867f6>] __riscv_sys_finit_module+0x176/0x2a8
[9.187365] [<ffffffff80889862>] do_trap_ecall_u+0xbe/0x130
[9.192922] [<ffffffff808920bc>] ret_from_exception+0x0/0x64
[9.198573] Code: 0009 b7e9 6797 014d a783 85a7 c799 4785 0717 0100 (0123) aef7
[9.205994] ---[ end trace 0000000000000000 ]---
This is because we called riscv_noncoherent_supported() for all the stages
during IOCP probe. riscv_noncoherent_supported() function sets
noncoherent_supported variable to true which has an annotation set to
"__ro_after_init" due to which we were seeing the above splat. Fix this by
probing for IOCP only once in boot stage by having a boolean variable
"done" which will be set to true upon IOCP probe in errata_probe_iocp()
and we bail out early if "done" is set to true.
While at it make return type of errata_probe_iocp() to void as we were
not checking the return value in andes_errata_patch_func().
Fixes: e021ae7f5145 ("riscv: errata: Add Andes alternative ports")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yu Chien Peter Lin <peterlin@andestech.com>
Link: https://lore.kernel.org/r/20231130212647.108746-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|
|
This fixes two bugs in SCS initialization for secondary CPUs. First,
the SCS was not initialized at all in the spinwait boot path. Second,
the code for the SBI HSM path attempted to initialize the SCS before
enabling the MMU. However, that involves dereferencing the thread
pointer, which requires the MMU to be enabled.
Fix both issues by setting up the SCS in the common secondary entry
path, after enabling the MMU.
Fixes: d1584d791a29 ("riscv: Implement Shadow Call Stack")
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20231121211958.3158576-1-samuel.holland@sifive.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|
|
Verdin SPI_1 interface has a dedicated hardware controlled chip select
that is currently configured in the same pinctrl group as MISO/MOSI/CLK,
however it is possible that it can be used only as a standard GPIO be it
a chip select or not.
To maximize flexibility and avoid duplication in the carrier board dts
files move the SPI_1 CS in a dedicated pinctrl and also adds an
additional pinctrl to simplify using SPI_1 CS as a GPIO.
Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20231205184605.35225-2-francesco@dolcini.it
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The GPIO Expander has a line name defined as GPIO0_HDMI_RST. This line
is no longer associated with the HDMI Reset so we removed it.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20231204222811.2344460-3-ggiordano@phytec.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The DSS outputs DPI signals via its second video port (VP2). The DPI
output from DSS is 24 bits (RGB888) and is forwarded to an HDMI
transmitter (SIL9022) on the board.
Add pinmux for DSS DPI output and HDMI Interrupt.
Add DT nodes for SIL9022 HDMI transmitter (TX), and the HDMI connector
on the phyBOARD-Lyra.
Additionally, connect the output of DSS (VP2) with input of the HDMI TX,
and the output of HDMI TX to the input of the HDMI connector.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20231204222811.2344460-2-ggiordano@phytec.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
The gpio-expander on i2c-1 has a maximum frequency of 100kHz. Update our
main_i2c1 frequency to allow the nxp,pcf8574 gpio-expander to function
properly.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20231204222811.2344460-1-ggiordano@phytec.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Communication between the R5F subsystem and Linux takes place using DMA
memory regions and mailboxes. Here we add DT nodes for the memory
regions and mailboxes to facilitate communication between the R5
clusters and Linux as remoteproc will fail to start if no memory
regions or mailboxes are provided.
Fixes: c48ac0efe6d7 ("arm64: dts: ti: Add support for phyBOARD-Electra-AM642")
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20231204212304.1736306-1-ggiordano@phytec.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
This is a backport of a fix that was done in OpenSBI: ec0559eb315b
("lib: sbi_misaligned_ldst: Fix handling of C.SWSP and C.SDSP").
Unlike C.LWSP/C.LDSP, these encodings can be used with the zero
register, so checking that the rs2 field is non-zero is unnecessary.
Additionally, the previous check was incorrect since it was checking
the immediate field of the instruction instead of the rs2 field.
Fixes: 956d705dd279 ("riscv: Unaligned load/store handling for M_MODE")
Signed-off-by: Clément Léger <cleger@rivosinc.com>
Link: https://lore.kernel.org/r/20231103090223.702340-1-cleger@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|
|
Extensions are getting added quickly and their hwprobe bits will soon
exceed 31 (which pair values accommodate, since they're of type u64).
However, in one tree, where a bunch of extensions got merged prior to
zicboz, zicboz already got pushed to bit 32. Pushing it exposed a
32-bit compilation bug, since unsigned long was used instead of u64.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202310311801.hxduISrr-lkp@intel.com/
Fixes: 9c7646d5ffd2 ("RISC-V: hwprobe: Expose Zicboz extension and its block size")
Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
Link: https://lore.kernel.org/r/20231101141908.192198-2-ajones@ventanamicro.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|
|
The system controller's flash can be accessed via an MSS-exposed QSPI
controller sitting, which sits between the mailbox's control & data
registers. On Icicle, it has an MT25QL01GBBB8ESF connected to it.
The system controller and MSS both have separate QSPI controllers, both
of which can access the flash, although the system controller takes
priority.
Unfortunately, on engineering sample silicon, such as that on Icicle
kits, the MSS' QSPI controller cannot write to the flash due to a bug.
As a workaround, a QSPI controller can be implemented in the FPGA
fabric and the IO routing modified to connect it to the flash in place
of the "hard" controller in the MSS.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
Use opcodes available to both rv32 and rv64 in uleb128 module linking
test.
Fixes: af71bc194916 ("riscv: Add tests for riscv module loading")
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://lore.kernel.org/lkml/1d7c71ee-5742-4df4-b8ef-a2aea0a624eb@infradead.org/
Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Link: https://lore.kernel.org/r/20231122-module_fixup-v2-1-dfb9565e9ea5@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|
|
JEDEC standard JESD84-B51 defines the eMMC Data Strobe line, which is
currently used only in HS400 mode, as a device->host clock signal that
"is used only in read operation. The Data Strobe is always High-Z (not
driven by the device and pulled down by RDS) or Driven Low in write
operation, except during CRC status response." RDS is a pull-down
resistor specified in the 10K-100K ohm range. Thus per the standard, the
Data Strobe is always pulled to ground (by the eMMC and/or RDS) during
write operations.
Evidently, the eMMC host controller in the RK3588 considers an active
voltage on the eMMC-DS line during a write to be an error.
The default (i.e. hardware reset, and Rockchip BSP) behavior for the
RK3588 is to activate the eMMC-DS pin's builtin pull-down. As a result,
many RK3588 board designers do not bother adding a dedicated RDS
resistor, instead relying on the RK3588's internal bias. The current
devicetree, however, disables this bias (`pcfg_pull_none`), breaking
HS400-mode writes for boards without a dedicated RDS, but with an eMMC
chip that chooses to High-Z (instead of drive-low) the eMMC-DS line.
(The Turing RK1 is one such board.)
Fix this by changing the bias in the (common) emmc_data_strobe case to
reflect the expected hardware/BSP behavior. This is unlikely to cause
regressions elsewhere: the pull-down is only relevant for High-Z eMMCs,
and if this is redundant with a (dedicated) RDS resistor, the effective
result is only a lower resistance to ground -- where the range of
tolerance is quite high. If it does, it's better fixed in the specific
devicetrees.
Fixes: d85f8a5c798d5 ("arm64: dts: rockchip: Add rk3588 pinctrl data")
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Link: https://lore.kernel.org/r/20231205202900.4617-2-CFSworks@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Per imx23-clock.yaml and imx28-clock.yaml, fsl,clkctrl is not a valid
compatible string.
Remove it to fix the following dt-schema warning:
imx28-evk.dtb: clkctrl@80040000: compatible: ['fsl,imx28-clkctrl', 'fsl,clkctrl'] is too long
from schema $id: http://devicetree.org/schemas/clock/imx28-clock.yaml#
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Per root-node.yaml, 'model' is a required property.
Pass it to fix the following dt-schema warning:
imx28-xea.dtb: /: 'model' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml#
Signed-off-by: Fabio Estevam <festevam@denx.de>
Fixes: 445ae16ac1c5 ("ARM: dts: imx28: Add DTS description of imx28 based XEA board")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
The timer nodes declare compatibility with "fsl,imx6sx-gpt", which
itself is compatible with "fsl,imx6dl-gpt". Switch the fallback
compatible from "fsl,imx6sx-gpt" to "fsl,imx6dl-gpt".
Fixes: 949673450291 ("ARM: dts: add imx7d soc dtsi file")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Roland Hieber <rhi@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Make sure that the wifi regulator is always on. The wifi driver itself
puts the wifi module into suspend mode. If we cut the power the driver
will crash when resuming from suspend.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Fixes: ad0de4ceb706 ("arm64: dts: freescale: add initial apalis imx8 aka quadmax module support")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Release the id allocated in 'mmdc_pmu_init' when 'devm_kasprintf'
return NULL
Suggested-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Fixes: e76bdfd7403a ("ARM: imx: Added perf functionality to mmdc driver")
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Change the gpio node name to align with register address.
Fixes: ac7bcf48ddba ("arm64: dts: imx8ulp: update gpio node")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Change the gpio node name to align with register address
Fixes: c1d0782b5fc3 ("arm64: dts: imx93: update gpio node")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
"nic_media" clock should be enabled when power on/off mediamix, otherwise
power on/off will fail. Because "media_axi_root" clock is the parent of
"nic_media" clock, so replace "media_axi_clock" clock with "nic_media"
clock in mediamix node.
Link: https://github.com/nxp-imx/linux-imx/commit/ce18e6d0071ae9df5486af8613708ebe920484be
Fixes: f2d03ba997cb ("arm64: dts: imx93: reorder device nodes")
Fixes: e85d3458a804 ("arm64: dts: imx93: add src node")
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Add imx8qm's own pm, otherwise the following panic will
occur during the startup process:
Kernel panic - not syncing: Asynchronous SError Interrupt
Hardware name: Freescale i.MX8QM MEK (DT)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
dump_backtrace+0x98/0xf0
show_stack+0x18/0x24
dump_stack_lvl+0x60/0xac
dump_stack+0x18/0x24
panic+0x340/0x3a0
nmi_panic+0x8c/0x90
arm64_serror_panic+0x6c/0x78
do_serror+0x3c/0x78
el1h_64_error_handler+0x38/0x50
el1h_64_error+0x64/0x68
fsl_edma_chan_mux+0x98/0xdc
fsl_edma_probe+0x278/0x898
platform_probe+0x68/0xd8
really_probe+0x110/0x27c
__driver_probe_device+0x78/0x12c
driver_probe_device+0x3c/0x118
__device_attach_driver+0xb8/0xf8
bus_for_each_drv+0x84/0xe4
__device_attach+0xfc/0x18c
device_initial_probe+0x14/0x20
Fixes: e4d7a330fb7a ("arm64: dts: imx8: add edma[0..3]")
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
i.MX8QXP supports inverted PWM output, thus #pwm-cells needs to be set
to 3.
Fixes: f1d6a6b991ef9 ("arm64: dts: imx8qxp: add adma_pwm in adma")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
i.MX8QM/QXP supports inverted PWM output, thus #pwm-cells needs to be set
to 3.
Fixes: 23fa99b205ea ("arm64: dts: freescale: imx8-ss-lsio: add support for lsio_pwm0-3")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
The "fsl,clkctrl" compatible string is not documented.
It is used only to find the base address of the clock controller.
Instead of searching for an undocumented compatible string, search
for "fsl,imx23-clkctrl" and "fsl,imx28-clkctrl".
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Per memory.yaml, 'device_type' is a required property.
Pass it to fix the following dt-schema warning:
imx28-xea.dtb: /: memory@40000000: 'device_type' is a required property
from schema $id: http://devicetree.org/schemas/memory.yaml#
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
According to gpio-mxs.yaml, only "fsl,imx23-gpio" or "fsl,imx28-gpio"
are valid compatible strings.
This fixes the following dt-schema warnings:
imx23-evk.dtb: pinctrl@80018000: gpio@0:compatible: ['fsl,imx23-gpio', 'fsl,mxs-gpio'] is too long
from schema $id: http://devicetree.org/schemas/gpio/gpio-mxs.yaml#
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Per sgtl5000.yaml, '#sound-dai-cells' is a required property.
Pass it to fix the following dt-schema warning:
imx28-tx28.dtb: sgtl5000@a: '#sound-dai-cells' is a required property
from schema $id: http://devicetree.org/schemas/sound/sgtl5000.yaml#
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
No functional changes.
Adjust to comply with dt-schema requirements
and make possible to validate values.
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Add Toradex Verdin IMX8MP Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.
https://www.toradex.com/products/carrier-board/mallow-carrier-board
Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Add Toradex Verdin IMX8MM Mallow carrier board support. Mallow is a
low-cost carrier board in the Verdin family with a small form factor and
build for volume production making it ideal for industrial and embedded
applications.
https://www.toradex.com/products/carrier-board/mallow-carrier-board
Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
As per Rob Herring's feedback:
"The ethernet device should have a node name of
'ethernet'. The 'pcie' node name and 'device_type = "pci"' is for PCI
buses/bridges only."
Do it as suggested.
Fixes: d61c5068729a ("arm64: dts: imx8mm-venice-gw7: Fix pci sub-nodes")
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Since commit 8208181fe536 ("clk: imx: composite-8m:
Add imx8m_divider_determine_rate") the lcdif controller has
had the ability to set the lcdif_pixel rate which propagates
up the tree and sets the video_pll1 rate automatically.
By setting this value low, it will force the recalculation of
video_pll1 to the lowest rate needed by lcdif instead of
dividing a larger clock down to the desired clock speed. This
has the advantage of being able to lower the video_pll1 rate
from 594MHz to 148.5MHz when operating at 1080p. It can go even
lower when operating at lower resolutions and refresh rates.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> # Kontron BL i.MX8MM
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
There are two clock-rate assignments for video_pll1, and the
only one it should really have belongs inside the lcdif node,
since it's the only consumer of this clock. Remove it from
the clk node.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> # Kontron BL i.MX8MM
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
