| Age | Commit message (Collapse) | Author |
|---|
|
The Radxa Rock 5 ITX board exposes an HDMI input exactly the same way as
the Rock 5B, but this was not reflected in its DTS.
Change the rk3588-rock-5-itx to configure and enable the hdmi_receiver
and hdmi_receiver_cma nodes.
The hot-plug detection (HPD) pin keeps the hdmirx_det name rather than
the hdmirx_hpd name used in other boards since that is what matches the
official schematics (HDMIIRX_DET_L).
The configurations were confirmed to be identical on the downstream
Radxa kernel, and this has been tested to work on a Rock 5 ITX board
running kernel 6.19.3.
Signed-off-by: Pedro Alves <pta2002@pta2002.com>
Link: https://patch.msgid.link/20260323-radxa-r5-itx-hdmirx-v2-1-c52501909577@pta2002.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
APQ8084 is one of the platforms which gained very little interest
upstream. It doesn't look like the there was any interest in these
devices since December 2019. Two devices supported upstream have very
minumal DT files. Start forgetting about the platform by
removing DT files.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260325-drop-8084-dt-v1-1-a0255a404355@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
It has been reported that since commit 752a0d1d483e9 ("arm64: mm:
Provide level hint for flush_tlb_page()"), the arm64
check_hugetlb_options selftest has been locking up while running "Check
child hugetlb memory with private mapping, sync error mode and mmap
memory".
This is due to hugetlb (and THP) helpers casting their PMD/PUD entries
to PTE and calling __ptep_set_access_flags(), which issues a
__flush_tlb_page(). Now that this is hinted for level 3, in this case,
the TLB entry does not get evicted and we end up in a spurious fault
loop.
Fix this by creating a __ptep_set_access_flags_anysz() function which
takes the pgsize of the entry. It can then add the appropriate hint. The
"_anysz" approach is the established pattern for problems of this class.
Reported-by: Aishwarya TCV <Aishwarya.TCV@arm.com>
Fixes: 752a0d1d483e ("arm64: mm: Provide level hint for flush_tlb_page()")
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
The LVDS Panel was never shipped from Beacon, and there are device
tree errors, so rather than trying to fix them, remove it instead.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260325162735.24467-1-aford173@gmail.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
When checking dts involving the r9a06g032.dtsi file, the following kind
of warnings are reported:
Missing property '#address-cells' in node xxx, using 0 as fallback
Indeed, #address-cells is not present in the GIC interrupt controller
node.
Fix it adding the missing property.
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property in PCI node and in IRQ mux node consists of
several components and the component related to "parent unit
address", which size is defined by '#address-cells' of the node
pointed to by the interrupt-parent component, is not used (=0)
No functional change.
Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260325095718.388157-1-herve.codina@bootlin.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The Renesas RZ/V2N SoC (a.k.a. r9a09g056) comes with 4 CA55
cores and 1 CM33 core.
While the user manual doesn't explicitly specify which cores
should have access to particular watchdogs, it turns out that
(similarly to the Renesas RZ/V2H(P)) it only makes sense for
Linux to use WDT1.
Remove DT nodes wdt{0,2,3} from the RZ/V2N SoC specific dtsi
to make it compliant with the original design intent.
This change is harmless as there are no users for the nodes
being stripped out of this device tree.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260324225239.19136-2-fabrizio.castro.jz@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add a DT overlay to bind the Olimex MIPI-HDMI dual-lane DSI-to-HDMI adapter
on the Retronix R-Car V4H Sparrow Hawk board.
Current device link is at https://www.olimex.com/Products/IoT/ESP32-P4/MIPI-HDMI/open-source-hardware
Signed-off-by: Scott Murray <scott.murray@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260320025328.509003-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The RZ Smarc Carrier-II board has PCIe slots mounted on it.
Enable PCIe support.
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260318085119.44717-5-john.madieu.xa@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The RZ/G3E SMARC SoM has a fixed 100 MHz reference clock generator
for PCIe. Model it as a fixed-clock and assign it to the PCIe port.
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260318085119.44717-4-john.madieu.xa@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The RZ/G3E SoC family features an x2 PCIe IP. Add the PCIe node.
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260318085119.44717-3-john.madieu.xa@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The KSZ9131 schema does not document the "txdv-skew-psec" property,
neither does the kernel driver support this property. It does however
document and support the "txen-skew-psec" property. Fix what is likely
a copy-paste error from the matching "rxdv-skew-psec" property, use the
"txen-skew-psec" property instead of the "txdv-skew-psec" property.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260313164008.40933-5-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The Microchip KSZ9131 PHY schema indicates that the compatible string
"ethernet-phy-id0022.1640" must not be followed by any other compatible
string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260313164008.40933-4-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The Realtek RTL8211F PHY schema indicates that the compatible string
"ethernet-phy-id001c.c916" must not be followed by any other compatible
string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260313164008.40933-3-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The Realtek RTL8211E PHY schema indicates that the compatible string
"ethernet-phy-id001c.c915" must not be followed by any other compatible
string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260313164008.40933-2-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add a DT overlay to bind the WaveShare 13.3inch 1920x1080 DSI Capacitive
Touch Display on the Retronix R-Car V4H Sparrow Hawk board.
Current device link is at https://www.waveshare.com/13.3inch-dsi-lcd.htm
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260117005028.126361-2-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Mark the first 128 MiB of DRAM as reserved. The first 128 MiB of DRAM
may optionally be used by TFA and other firmware for its own purposes,
and in such case, Linux must not use this memory.
On this platform, U-Boot runs in EL3 and starts TFA BL31 and Linux from
a single combined fitImage. U-Boot has full access to all memory in the
0x40000000..0xbfffffff range, as well memory in the memory banks in the
64-bit address ranges, and therefore U-Boot patches this full complete
view of platform memory layout into the DT that is passed to the next
stage.
The next stage is TFA BL31 and then the Linux kernel. The TFA BL31 does
not modify the DT passed from U-Boot to TFA BL31 and then to Linux with
any new reserved-memory {} node to reserve memory areas used by the TFA
BL31 to prevent the next stage from using those areas, which lets Linux
to use all of the available DRAM as described in the DT that was passed
in by U-Boot, including the areas that are newly utilized by TFA BL31.
In case of high DRAM utilization, for example in case of four instances
of "memtester 3900M" running in parallel, unless the memory used by TFA
BL31 is properly reserved, Linux may use and corrupt the memory used by
TFA BL31, which would often lead to system becoming unresponsive.
Until TFA BL31 can properly fill its own reserved-memory node into the
DT, and to assure older versions of TFA BL31 do not cause problems, add
explicitly reserved-memory {} node which prevents Linux from using the
first 128 MiB of DRAM.
Note that TFA BL31 can be adjusted to use different memory areas, this
newly added reserved-memory {} node follows longer-term practice on the
R-Car SoCs where the first 128 MiB of DRAM is reserved for firmware use.
In case user does modify TFA BL31 to use different memory ranges, they
must either use a future version of TFA BL31 which properly patches a
reserved-memory {} node into the DT, or they must adjust the address
ranges of this reserved-memory {} node accordingly.
Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support")
Cc: stable@vger.kernel.org
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260324143342.17872-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
dma-mapping fixes for Linux 7.0
A set of fixes for DMA-mapping subsystem, which resolve false-positive
warnings from KMSAN and DMA-API debug (Shigeru Yoshida and Leon
Romanovsky) as well as a simple build fix (Miguel Ojeda).
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
|
|
Enable STMicroelectronics STM32 display support as module.
This includes:
* DRM_STM
* DRM_STM_LVDS
* BACKLIGHT_GPIO
* TOUCHSCREEN_ILI210X
This display is used on several SoCs and boards such as STM32MP257F-EV1
and STM32MP257F-DK.
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Tested-by: Yannick Fertre <yannick.fertre@foss.st.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260205-master-v1-1-dcefcabc2934@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Enable the following IPs on stm32mp257f-dk in order to get display:
* LTDC
* LVDS
* WSVGA LVDS panel (1024x600)
* Panel LVDS backlight as GPIO backlight
* ILI2511 i2c touchscreen
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Link: https://lore.kernel.org/r/20260210-display-v2-9-0592bd514958@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Describe power supplies for stm32mp257f-dk board.
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Link: https://lore.kernel.org/r/20260210-display-v2-8-0592bd514958@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Enable the following IPs on stm32mp235f-dk in order to get display:
* LTDC
* LVDS
* WSVGA LVDS panel (1024x600)
* Panel LVDS backlight as GPIO backlight
* ILI2511 i2c touchscreen
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Link: https://lore.kernel.org/r/20260210-display-v2-7-0592bd514958@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Describe power supplies for stm32mp235f-dk board.
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Link: https://lore.kernel.org/r/20260210-display-v2-6-0592bd514958@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Make the syscfg node a clock provider so clock consumers can reach child
clocks through device-tree.
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Link: https://lore.kernel.org/r/20260210-display-v2-5-0592bd514958@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
The LVDS is used on STM32MP2 as a display interface.
Add the LVDS node.
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Link: https://lore.kernel.org/r/20260210-display-v2-4-0592bd514958@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Add the LTDC node for stm32mp235 SoC and handle its loopback clocks.
ck_ker_ltdc has the CLK_SET_RATE_PARENT flag. While having this flag is
semantically correct, it for now leads to an improper setting of the
clock rate. The ck_ker_ltdc parent clock is the flexgen 27, which does
not support changing rates yet. To overcome this issue, a fixed clock
can be used for the kernel clock.
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Link: https://lore.kernel.org/r/20260210-display-v2-3-0592bd514958@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
The LCD-TFT Display Controller (LTDC) handles display composition,
scaling and rotation. It provides a parallel digital RGB flow to be
used by display interfaces.
Add the LTDC node.
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Link: https://lore.kernel.org/r/20260210-display-v2-2-0592bd514958@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
stm32mp25-pinctrl.dtsi gathers all pinctrl groups from current and future
STM32MP25-based boards. Some groups may remain unused by any board,
resulting in wasted binary space.
Adding /omit-if-no-ref/ to the groups will remove unused groups from the
device tree blobs.
Use the following regex to update the file:
's/^\t[^:]\+: [^ ]\+ {$/\t\/omit-if-no-ref\/\n&/'
Also, merge the duplicated pinctrl_z node.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Link: https://lore.kernel.org/r/20260311-mp25_pinctrl_omit-v1-1-5a3d40046b10@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Add bootph-all property in bsec node to ensure that bsec node
is included in U-Boot device tree for all phases.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Link: https://lore.kernel.org/r/20260211-upstream_stm32mp21_bsec_nodes-v1-2-8379bf97b0bc@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Add BSEC support to STM32MP21 SoC family with SoC information:
- RPN = Device part number (BSEC_OTP_DATA9)
- PKG = package data register (Bits 2:0 of BSEC_OTP_DATA122)
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Link: https://lore.kernel.org/r/20260211-upstream_stm32mp21_bsec_nodes-v1-1-8379bf97b0bc@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Since the ETZPC system bus was introduced, misalignments have appeared
in some nodes moved under the etzpc parent node.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Link: https://lore.kernel.org/r/20260304-mp1x_alignment_issues-v1-2-19a8013782a5@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Since the ETZPC system bus was introduced, misalignments have appeared
in some nodes moved under the etzpc parent node.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Link: https://lore.kernel.org/r/20260304-mp1x_alignment_issues-v1-1-19a8013782a5@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Add nodes for i2c2 and i2c8 available on stm32mp235f-dk board.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20260224-stm32-i2c-dt-updates-v1-9-347cf6fca7d1@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Add nodes for i2c2 and i2c8 available on stm32mp257f-dk board.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20260224-stm32-i2c-dt-updates-v1-8-347cf6fca7d1@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Keep DMA resources available by avoiding usage of DMA for i2c transfers
on stm32mp257f-ev1 board.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20260224-stm32-i2c-dt-updates-v1-7-347cf6fca7d1@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Add a 2nd set of i2c2 pinmux nodes (i2c2_pins_b/i2c2_sleep_pins_b)
in stm32mp25-pinctrl.dtsi in order to be used on the stm32mp257f-dk
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20260224-stm32-i2c-dt-updates-v1-6-347cf6fca7d1@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Update all i2c nodes with the following properties:
- replace interrupts with interrupts-extended and rely on exti
- add the wakeup-source property
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20260224-stm32-i2c-dt-updates-v1-5-347cf6fca7d1@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Update all i2c nodes with the following properties:
- replace interrupts with interrupts-extended and rely on exti
- add the wakeup-source property
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20260224-stm32-i2c-dt-updates-v1-4-347cf6fca7d1@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Since DMA resources are limited, remove the DMA related properties
of i2c2 and i2c5 in stm32mp157c-ev1.dts.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20260224-stm32-i2c-dt-updates-v1-3-347cf6fca7d1@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Update all i2c nodes with the following properties:
- replace interrupts with interrupts-extended and rely on exti
- add the wakeup-source property
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20260224-stm32-i2c-dt-updates-v1-2-347cf6fca7d1@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Update all i2c nodes with the following properties:
- replace interrupts with interrupts-extended and rely on exti
- add dma properties
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20260224-stm32-i2c-dt-updates-v1-1-347cf6fca7d1@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
The following DTOs are supported on STM32MP15xx DHCOM PDK2:
- DH 460-200 SRAM board in header X11
- DH 497-200 adapter card with EDT ETM0700G0EDH6 Parallel RGB panel
- DH 505-200 adapter card with Chefree CH101OLHLWH-002 LVDS panel
- DH 531-100 SPI/I2C board in header X21
- DH 531-200 SPI/I2C board in header X22
- DH 560-200 7" LCD board in header X12
- DH 638-100 mezzanine card with RPi 7" DSI panel attached on top
- DH 672-100 expansion card, which contains CAN/FD transceiver and
enables PDK2 to use one more CAN/FD interface
The following DTOs are supported on STM32MP15xx DHCOM DRC02:
- Enable configuration where the DHSOM inserted into the DRC02 has
RSI 9116 WiFi populated on the SoM and where the microSD slot on
the bottom of DRC02 must not be used.
This permits a non-default configuration of the SoM and DRC02 board
used for custom device setup with on-SoM WiFi.
The following DTOs are supported on STM32MP15xx DHCOM PicoITX:
- DH 548-200 adapter card with Multi-Inno MI0700D4T-6 7" DPI panel
- DH 553-100 adapter card with Team Source Display TST043015CMHX 4.3" DPI panel
- DH 626-100 adapter card with Chefree CH101OLHLWH-002 LVDS panel
The following DTOs are supported on STM32MP15xx DHCOR Avenger96:
- FDCAN1 on low-speed expansion X6
- FDCAN2 on low-speed expansion X6
- AT24C04 I2C EEPROM on low-speed expansion X6 I2C1
- AT24C04 I2C EEPROM on low-speed expansion X6 I2C2
- AT25AA010A SPI EEPROM on low-speed expansion X6 SPI2
- 96boards OV5640 mezzanine card with sensor connected to port J3.
- DH 644-100 mezzanine card with Orisetech OTM8009A DSI panel
- DH 644-100 mezzanine card with RPi 7" DSI panel
The following DTOs are supported on STM32MP13xx DHCOR DHSBC:
- joy-IT RB-TFT3.2-V2 240x320 SPI LCD and XPT2046 resistive touch controller
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://lore.kernel.org/r/20260121085347.10368-3-marex@nabladev.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Enable CoreSight peripherals on the stm32mp135f-dk board.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Link: https://lore.kernel.org/r/20260226-debug_bus-v6-11-5d794697798d@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Enable CoreSight peripherals on the stm32mp157c-ev1 board.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Link: https://lore.kernel.org/r/20260226-debug_bus-v6-10-5d794697798d@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Enable CoreSight peripherals on the stm32mp15xx-dkx boards. All boards
including this file are embedding a dual core SoC so this change is
applicable.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Link: https://lore.kernel.org/r/20260226-debug_bus-v6-9-5d794697798d@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
On stm32mp1x boards, enable the debug bus so we always try to probe
the debug peripherals, if their status and the debug configuration
allow it.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Link: https://lore.kernel.org/r/20260226-debug_bus-v6-8-5d794697798d@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
Some peripherals cannot be probed if a debug configuration is not set
in the BSEC.
Introduce a debug bus that will check the debug subsystem accessibility
before probing these peripheral drivers.
Add Coresight peripheral nodes under this bus and add the appropriate
access-controllers property to the HDP node.
Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Link: https://lore.kernel.org/r/20260226-debug_bus-v6-7-5d794697798d@foss.st.com
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
|
|
The BeagleV Ahead board includes a micro HDMI connector (Type-D)
wired to the TH1520 SoC's HDMI transmitter.
Enable the display pipeline by adding the HDMI connector node,
connecting it to the HDMI controller, and activating the DPU
and HDMI nodes.
Signed-off-by: Robert Mazur <robert.mazur@imgtec.com>
Signed-off-by: Drew Fustini <fustini@kernel.org>
|
|
All CONFIG_ARCH_TEGRA_132_SOC-like symbols are now default for
ARCH_TEGRA, so drop redundant lines from defconfig. Tested with
comparing include/generated/autoconf.h.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
All CONFIG_ARCH_TEGRA_2x_SOC-like symbols are now default for
ARCH_TEGRA, so drop redundant lines from defconfigs. Tested with
comparing include/generated/autoconf.h.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Previously different architectures were using random sources of
differing strength and cost to decide the random kstack offset. A number
of architectures (loongarch, powerpc, s390, x86) were using their
timestamp counter, at whatever the frequency happened to be. Other
arches (arm64, riscv) were using entropy from the crng via
get_random_u16().
There have been concerns that in some cases the timestamp counters may
be too weak, because they can be easily guessed or influenced by user
space. And get_random_u16() has been shown to be too costly for the
level of protection kstack offset randomization provides.
So let's use a common, architecture-agnostic source of entropy; a
per-cpu prng, seeded at boot-time from the crng. This has a few
benefits:
- We can remove choose_random_kstack_offset(); That was only there to
try to make the timestamp counter value a bit harder to influence
from user space [*].
- The architecture code is simplified. All it has to do now is call
add_random_kstack_offset() in the syscall path.
- The strength of the randomness can be reasoned about independently
of the architecture.
- Arches previously using get_random_u16() now have much faster
syscall paths, see below results.
[*] Additionally, this gets rid of some redundant work on s390 and x86.
Before this patch, those architectures called
choose_random_kstack_offset() under arch_exit_to_user_mode_prepare(),
which is also called for exception returns to userspace which were *not*
syscalls (e.g. regular interrupts). Getting rid of
choose_random_kstack_offset() avoids a small amount of redundant work
for the non-syscall cases.
In some configurations, add_random_kstack_offset() will now call
instrumentable code, so for a couple of arches, I have moved the call a
bit later to the first point where instrumentation is allowed. This
doesn't impact the efficacy of the mechanism.
There have been some claims that a prng may be less strong than the
timestamp counter if not regularly reseeded. But the prng has a period
of about 2^113. So as long as the prng state remains secret, it should
not be possible to guess. If the prng state can be accessed, we have
bigger problems.
Additionally, we are only consuming 6 bits to randomize the stack, so
there are only 64 possible random offsets. I assert that it would be
trivial for an attacker to brute force by repeating their attack and
waiting for the random stack offset to be the desired one. The prng
approach seems entirely proportional to this level of protection.
Performance data are provided below. The baseline is v6.18 with rndstack
on for each respective arch. (I)/(R) indicate statistically significant
improvement/regression. arm64 platform is AWS Graviton3 (m7g.metal).
x86_64 platform is AWS Sapphire Rapids (m7i.24xlarge):
+-----------------+--------------+---------------+---------------+
| Benchmark | Result Class | per-cpu-prng | per-cpu-prng |
| | | arm64 (metal) | x86_64 (VM) |
+=================+==============+===============+===============+
| syscall/getpid | mean (ns) | (I) -9.50% | (I) -17.65% |
| | p99 (ns) | (I) -59.24% | (I) -24.41% |
| | p99.9 (ns) | (I) -59.52% | (I) -28.52% |
+-----------------+--------------+---------------+---------------+
| syscall/getppid | mean (ns) | (I) -9.52% | (I) -19.24% |
| | p99 (ns) | (I) -59.25% | (I) -25.03% |
| | p99.9 (ns) | (I) -59.50% | (I) -28.17% |
+-----------------+--------------+---------------+---------------+
| syscall/invalid | mean (ns) | (I) -10.31% | (I) -18.56% |
| | p99 (ns) | (I) -60.79% | (I) -20.06% |
| | p99.9 (ns) | (I) -61.04% | (I) -25.04% |
+-----------------+--------------+---------------+---------------+
I tested an earlier version of this change on x86 bare metal and it
showed a smaller but still significant improvement. The bare metal
system wasn't available this time around so testing was done in a VM
instance. I'm guessing the cost of rdtsc is higher for VMs.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Link: https://patch.msgid.link/20260303150840.3789438-3-ryan.roberts@arm.com
Signed-off-by: Kees Cook <kees@kernel.org>
|
