summaryrefslogtreecommitdiffstats
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2022-11-03arm64: dts: ti: k3-am65: Enable Mailbox nodes at the board levelAndrew Davis3-80/+16
Mailbox nodes defined in the top-level AM65x SoC dtsi files are incomplete and may not be functional unless they are extended with a chosen interrupt and connection to a remote processor. As the remote processors depend on memory nodes which are only known at the board integration level, these nodes should only be enabled when provided with the above information. Disable the Mailbox nodes in the dtsi files and only enable the ones that are actually used on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221028142417.10642-11-afd@ti.com
2022-11-03arm64: dts: ti: k3-am65: Enable PCIe nodes at the board levelAndrew Davis3-28/+5
PCIe nodes defined in the top-level AM65x SoC dtsi files are incomplete and will not be functional unless they are extended with a SerDes PHY. And usually only one of the two modes can be used at a time as they share a SerDes link. As the PHY and mode is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the PCIe nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221028142417.10642-10-afd@ti.com
2022-11-03arm64: dts: ti: k3-am65: Enable MCAN nodes at the board levelAndrew Davis3-16/+2
MCAN nodes defined in the top-level AM65x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the MCAN nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221028142417.10642-9-afd@ti.com
2022-11-03arm64: dts: ti: k3-am65: Enable MDIO nodes at the board levelAndrew Davis4-24/+5
MDIO nodes defined in the top-level AM65x SoC dtsi files are incomplete and will not be functional unless they are extended with a pinmux. As the attached PHY is only known about at the board integration level, these nodes should only be enabled when provided with this information. Disable the MDIO nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221028142417.10642-8-afd@ti.com
2022-11-03arm64: dts: ti: k3-am65: MDIO pinmux should belong to the MDIO nodeAndrew Davis1-1/+4
Although usually integrated as a child of an Ethernet controller, MDIO IP has an independent pinout. This pinout should be controlled by the MDIO node (so if it was to be disabled for instance, the pinmux state would reflect that). Move the MDIO pins pinmux to the MIDO nodes. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221028142417.10642-7-afd@ti.com
2022-11-03arm64: dts: ti: k3-am65: Enable ECAP nodes at the board levelAndrew Davis3-0/+3
ECAP nodes defined in the top-level AM65x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. (These and the EPWM nodes could be used to trigger internal actions but they are not used like that currently) As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the ECAP nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221028142417.10642-6-afd@ti.com
2022-11-03arm64: dts: ti: k3-am65: Enable EPWM nodes at the board levelAndrew Davis1-0/+6
EPWM nodes defined in the top-level AM65x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the EPWM nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221028142417.10642-5-afd@ti.com
2022-11-03arm64: dts: ti: k3-am65: Enable SPI nodes at the board levelAndrew Davis4-0/+10
SPI nodes defined in the top-level AM65x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the SPI nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221028142417.10642-4-afd@ti.com
2022-11-03arm64: dts: ti: k3-am65: Enable I2C nodes at the board levelAndrew Davis5-0/+21
I2C nodes defined in the top-level AM65x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the I2C nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221028142417.10642-3-afd@ti.com
2022-11-03arm64: dts: ti: k3-am65: Enable UART nodes at the board levelAndrew Davis7-13/+19
UART nodes defined in the top-level AM65x SoC dtsi files are incomplete and may not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the UART nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221028142417.10642-2-afd@ti.com
2022-11-03arm64: dts: ti: Rename clock-names adc_tsc_fck to fckMatt Ranostay4-6/+6
Avoid the following warnings from dt-schema by just renaming the clock-names string from adc_tsc_fck to fck so it matches the values in ti,am3359-tscadc.yaml tscadc@40200000: clock-names:0: 'fck' was expected Signed-off-by: Matt Ranostay <mranostay@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Judith Mendez <jm@ti.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20221024151648.394623-1-mranostay@ti.com
2022-10-28arm64: dts: ti: k3-j721s2: Enable I2C nodes at the board levelAndrew Davis4-24/+10
I2C nodes defined in the top-level J721s2 SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the I2C nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-13-afd@ti.com
2022-10-28arm64: dts: ti: k3-j721s2: Enable MCAN nodes at the board levelAndrew Davis4-68/+23
MCAN nodes defined in the top-level J721s2 SoC dtsi files are incomplete and may not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the MCAN nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-12-afd@ti.com
2022-10-28arm64: dts: ti: k3-j721s2: Enable Mailbox nodes at the board levelAndrew Davis2-96/+24
Mailbox nodes defined in the top-level J721s2 SoC dtsi files are incomplete and may not be functional unless they are extended with a chosen interrupt and connection to a remote processor. As the remote processors depend on memory nodes which are only known at the board integration level, these nodes should only be enabled when provided with the above information. Disable the Mailbox nodes in the dtsi files and only enable the ones that are actually used on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-11-afd@ti.com
2022-10-28arm64: dts: ti: k3-j7200: Enable Mailbox nodes at the board levelAndrew Davis2-40/+14
Mailbox nodes defined in the top-level J7200 SoC dtsi files are incomplete and may not be functional unless they are extended with a chosen interrupt and connection to a remote processor. As the remote processors depend on memory nodes which are only known at the board integration level, these nodes should only be enabled when provided with the above information. Disable the Mailbox nodes in the dtsi files and only enable the ones that are actually used on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-10-afd@ti.com
2022-10-28arm64: dts: ti: k3-j721e: Enable Mailbox nodes at the board levelAndrew Davis3-56/+22
Mailbox nodes defined in the top-level J721e SoC dtsi files are incomplete and may not be functional unless they are extended with a chosen interrupt and connection to a remote processor. As the remote processors depend on memory nodes which are only known at the board integration level, these nodes should only be enabled when provided with the above information. Disable the Mailbox nodes in the dtsi files and only enable the ones that are actually used on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-9-afd@ti.com
2022-10-28arm64: dts: ti: k3-j721s2: Enable UART nodes at the board levelAndrew Davis3-34/+16
UART nodes defined in the top-level J721s2 SoC dtsi files are incomplete and may not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the UART nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-8-afd@ti.com
2022-10-28arm64: dts: ti: k3-j7200: Enable I2C nodes at the board levelAndrew Davis3-0/+12
I2C nodes defined in the top-level J7200 SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the I2C nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-7-afd@ti.com
2022-10-28arm64: dts: ti: k3-j7200: Enable UART nodes at the board levelAndrew Davis3-35/+23
UART nodes defined in the top-level J7200 SoC dtsi files are incomplete and may not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the UART nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-6-afd@ti.com
2022-10-28arm64: dts: ti: k3-j721e: Enable MCAN nodes at the board levelAndrew Davis3-48/+20
MCAN nodes defined in the top-level J721e SoC dtsi files are incomplete and may not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the MCAN nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-5-afd@ti.com
2022-10-28arm64: dts: ti: k3-j721e: Enable MCASP nodes at the board levelAndrew Davis3-104/+13
MCASP nodes defined in the top-level J721e SoC dtsi files are incomplete and may not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the MCASP nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-4-afd@ti.com
2022-10-28arm64: dts: ti: k3-j721e: Enable I2C nodes at the board levelAndrew Davis4-20/+17
I2C nodes defined in the top-level J721e SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the I2C nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-3-afd@ti.com
2022-10-28arm64: dts: ti: k3-j721e: Enable UART nodes at the board levelAndrew Davis4-57/+37
UART nodes defined in the top-level J721e SoC dtsi files are incomplete and may not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the UART nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221020160305.18711-2-afd@ti.com
2022-10-28arm64: dts: ti: k3-am62: Enable OSPI nodes at the board levelAndrew Davis2-0/+2
OSPI nodes defined in the top-level AM62x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the OSPI nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221018211533.21335-11-afd@ti.com
2022-10-28arm64: dts: ti: k3-am62: Enable SDHCI nodes at the board levelAndrew Davis2-0/+5
SDHCI nodes defined in the top-level AM62x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the SDHCI nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221018211533.21335-10-afd@ti.com
2022-10-28arm64: dts: ti: k3-am62: Enable MCAN nodes at the board levelAndrew Davis2-4/+1
MCAN nodes defined in the top-level AM62x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the MCAN nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221018211533.21335-9-afd@ti.com
2022-10-28arm64: dts: ti: k3-am62: Enable MDIO nodes at the board levelAndrew Davis2-0/+2
MDIO nodes defined in the top-level AM62x SoC dtsi files are incomplete and will not be functional unless they are extended with a pinmux. As the attached PHY is only known about at the board integration level, these nodes should only be enabled when provided with this information. Disable the MDIO nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221018211533.21335-8-afd@ti.com
2022-10-28arm64: dts: ti: k3-am62: MDIO pinmux should belong to the MDIO nodeAndrew Davis1-2/+4
Although usually integrated as a child of an Ethernet controller, MDIO IP has an independent pinout. This pinout should be controlled by the MDIO node (so if it was to be disabled for instance, the pinmux state would reflect that). Move the MDIO pins pinmux to the MIDO nodes. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221018211533.21335-7-afd@ti.com
2022-10-28arm64: dts: ti: k3-am62: Enable ECAP nodes at the board levelAndrew Davis2-12/+3
ECAP nodes defined in the top-level AM62x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. (These and the EPWM nodes could be used to trigger internal actions but they are not used like that currently) As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the ECAP nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221018211533.21335-6-afd@ti.com
2022-10-28arm64: dts: ti: k3-am62: Enable EPWM nodes at the board levelAndrew Davis2-12/+3
EPWM nodes defined in the top-level AM62x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the EPWM nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221018211533.21335-5-afd@ti.com
2022-10-28arm64: dts: ti: k3-am62: Enable SPI nodes at the board levelAndrew Davis2-0/+5
SPI nodes defined in the top-level AM62x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the SPI nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221018211533.21335-4-afd@ti.com
2022-10-28arm64: dts: ti: k3-am62: Enable I2C nodes at the board levelAndrew Davis4-16/+8
I2C nodes defined in the top-level AM62x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the I2C nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221018211533.21335-3-afd@ti.com
2022-10-28arm64: dts: ti: k3-am62: Enable UART nodes at the board levelAndrew Davis4-24/+10
UART nodes defined in the top-level AM62x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the UART nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20221018211533.21335-2-afd@ti.com
2022-10-28arm64: dts: ti: k3-am64: Enable GPMC and ELM nodes at the board levelAndrew Davis3-16/+2
The GPMC node defined in the top-level AM64x SoC dtsi files are incomplete and will not be functional unless it is extended with pinmux information. As the pinmux is only known at the board integration level, this node should only be enabled when provided with this information. Disable the GPMC node in the dtsi file. Since the ELM is made to work with the GPMC, disable it too. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20221017192532.23825-11-afd@ti.com
2022-10-28arm64: dts: ti: k3-am64: Enable MCAN nodes at the board levelAndrew Davis3-8/+4
MCAN nodes defined in the top-level AM64x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the MCAN nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20221017192532.23825-10-afd@ti.com
2022-10-28arm64: dts: ti: k3-am64: Enable MDIO nodes at the board levelAndrew Davis3-16/+5
MDIO nodes defined in the top-level AM64x SoC dtsi files are incomplete and will not be functional unless they are extended with a pinmux. As the attached PHY is only known about at the board integration level, these nodes should only be enabled when provided with this information. Disable the MDIO nodes (in both CPSW and ICSSG) in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20221017192532.23825-9-afd@ti.com
2022-10-28arm64: dts: ti: k3-am64: MDIO pinmux should belong to the MDIO nodeAndrew Davis2-4/+8
Although usually integrated as a child of an Ethernet controller, MDIO IP has an independent pinout. This pinout should be controlled by the MDIO node (so if it was to be disabled for instance, the pinmux state would reflect that). Move the MDIO pins pinmux to the MIDO nodes. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20221017192532.23825-8-afd@ti.com
2022-10-28arm64: dts: ti: k3-am64: Enable PCIe nodes at the board levelAndrew Davis3-9/+3
PCIe nodes defined in the top-level AM64x SoC dtsi files are incomplete and will not be functional unless they are extended with a SerDes PHY. And usually only one of the two modes can be used at a time as they share a SerDes link. As the PHY and mode is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the PCIe nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20221017192532.23825-7-afd@ti.com
2022-10-28arm64: dts: ti: k3-am64: Enable ECAP nodes at the board levelAndrew Davis3-16/+5
ECAP nodes defined in the top-level AM64x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. (These and the EPWM nodes could be used to trigger internal actions but they are not used like that currently) As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the ECAP nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20221017192532.23825-6-afd@ti.com
2022-10-28arm64: dts: ti: k3-am64: Enable EPWM nodes at the board levelAndrew Davis3-80/+9
EPWM nodes defined in the top-level AM64x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the EPWM nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20221017192532.23825-5-afd@ti.com
2022-10-28arm64: dts: ti: k3-am64: Enable SPI nodes at the board levelAndrew Davis4-16/+8
SPI nodes defined in the top-level AM64x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the SPI nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20221017192532.23825-4-afd@ti.com
2022-10-28arm64: dts: ti: k3-am64: Enable I2C nodes at the board levelAndrew Davis4-20/+8
I2C nodes defined in the top-level AM64x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the I2C nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20221017192532.23825-3-afd@ti.com
2022-10-28arm64: dts: ti: k3-am64: Enable UART nodes at the board levelAndrew Davis4-56/+11
UART nodes defined in the top-level AM64x SoC dtsi files are incomplete and will not be functional unless they are extended with pinmux information. As the pinmux is only known at the board integration level, these nodes should only be enabled when provided with this information. Disable the UART nodes in the dtsi files and only enable the ones that are actually pinned out on a given board. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20221017192532.23825-2-afd@ti.com
2022-10-16Merge tag 'random-6.1-rc1-for-linus' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/crng/random Pull more random number generator updates from Jason Donenfeld: "This time with some large scale treewide cleanups. The intent of this pull is to clean up the way callers fetch random integers. The current rules for doing this right are: - If you want a secure or an insecure random u64, use get_random_u64() - If you want a secure or an insecure random u32, use get_random_u32() The old function prandom_u32() has been deprecated for a while now and is just a wrapper around get_random_u32(). Same for get_random_int(). - If you want a secure or an insecure random u16, use get_random_u16() - If you want a secure or an insecure random u8, use get_random_u8() - If you want secure or insecure random bytes, use get_random_bytes(). The old function prandom_bytes() has been deprecated for a while now and has long been a wrapper around get_random_bytes() - If you want a non-uniform random u32, u16, or u8 bounded by a certain open interval maximum, use prandom_u32_max() I say "non-uniform", because it doesn't do any rejection sampling or divisions. Hence, it stays within the prandom_*() namespace, not the get_random_*() namespace. I'm currently investigating a "uniform" function for 6.2. We'll see what comes of that. By applying these rules uniformly, we get several benefits: - By using prandom_u32_max() with an upper-bound that the compiler can prove at compile-time is ≤65536 or ≤256, internally get_random_u16() or get_random_u8() is used, which wastes fewer batched random bytes, and hence has higher throughput. - By using prandom_u32_max() instead of %, when the upper-bound is not a constant, division is still avoided, because prandom_u32_max() uses a faster multiplication-based trick instead. - By using get_random_u16() or get_random_u8() in cases where the return value is intended to indeed be a u16 or a u8, we waste fewer batched random bytes, and hence have higher throughput. This series was originally done by hand while I was on an airplane without Internet. Later, Kees and I worked on retroactively figuring out what could be done with Coccinelle and what had to be done manually, and then we split things up based on that. So while this touches a lot of files, the actual amount of code that's hand fiddled is comfortably small" * tag 'random-6.1-rc1-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: prandom: remove unused functions treewide: use get_random_bytes() when possible treewide: use get_random_u32() when possible treewide: use get_random_{u8,u16}() when possible, part 2 treewide: use get_random_{u8,u16}() when possible, part 1 treewide: use prandom_u32_max() when possible, part 2 treewide: use prandom_u32_max() when possible, part 1
2022-10-14Merge tag 'arm64-fixes' of ↵Linus Torvalds7-4/+46
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Cortex-A55 errata workaround (repeat TLBI) - AMPERE1 added to the Spectre-BHB affected list - MTE fix to avoid setting PG_mte_tagged if no tags have been touched on a page - Fixed typo in the SCTLR_EL1.SPINTMASK bit naming (the commit log has other typos) - perf: return value check in ali_drw_pmu_probe(), ALIBABA_UNCORE_DRW_PMU dependency on ACPI * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Add AMPERE1 to the Spectre-BHB affected list arm64: mte: Avoid setting PG_mte_tagged if no tags cleared or restored MAINTAINERS: rectify file entry in ALIBABA PMU DRIVER drivers/perf: ALIBABA_UNCORE_DRW_PMU should depend on ACPI drivers/perf: fix return value check in ali_drw_pmu_probe() arm64: errata: Add Cortex-A55 to the repeat tlbi list arm64/sysreg: Fix typo in SCTR_EL1.SPINTMASK
2022-10-12Merge tag 'mm-nonmm-stable-2022-10-11' of ↵Linus Torvalds2-7/+0
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull non-MM updates from Andrew Morton: - hfs and hfsplus kmap API modernization (Fabio Francesco) - make crash-kexec work properly when invoked from an NMI-time panic (Valentin Schneider) - ntfs bugfixes (Hawkins Jiawei) - improve IPC msg scalability by replacing atomic_t's with percpu counters (Jiebin Sun) - nilfs2 cleanups (Minghao Chi) - lots of other single patches all over the tree! * tag 'mm-nonmm-stable-2022-10-11' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (71 commits) include/linux/entry-common.h: remove has_signal comment of arch_do_signal_or_restart() prototype proc: test how it holds up with mapping'less process mailmap: update Frank Rowand email address ia64: mca: use strscpy() is more robust and safer init/Kconfig: fix unmet direct dependencies ia64: update config files nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failure fork: remove duplicate included header files init/main.c: remove unnecessary (void*) conversions proc: mark more files as permanent nilfs2: remove the unneeded result variable nilfs2: delete unnecessary checks before brelse() checkpatch: warn for non-standard fixes tag style usr/gen_init_cpio.c: remove unnecessary -1 values from int file ipc/msg: mitigate the lock contention with percpu counter percpu: add percpu_counter_add_local and percpu_counter_sub_local fs/ocfs2: fix repeated words in comments relay: use kvcalloc to alloc page array in relay_alloc_page_array proc: make config PROC_CHILDREN depend on PROC_FS fs: uninline inode_maybe_inc_iversion() ...
2022-10-12arm64: Add AMPERE1 to the Spectre-BHB affected listD Scott Phillips2-0/+10
Per AmpereOne erratum AC03_CPU_12, "Branch history may allow control of speculative execution across software contexts," the AMPERE1 core needs the bhb clearing loop to mitigate Spectre-BHB, with a loop iteration count of 11. Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com> Link: https://lore.kernel.org/r/20221011022140.432370-1-scott@os.amperecomputing.com Reviewed-by: James Morse <james.morse@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-10-12arm64: mte: Avoid setting PG_mte_tagged if no tags cleared or restoredCatalin Marinas2-3/+13
Prior to commit 69e3b846d8a7 ("arm64: mte: Sync tags for pages where PTE is untagged"), mte_sync_tags() was only called for pte_tagged() entries (those mapped with PROT_MTE). Therefore mte_sync_tags() could safely use test_and_set_bit(PG_mte_tagged, &page->flags) without inadvertently setting PG_mte_tagged on an untagged page. The above commit was required as guests may enable MTE without any control at the stage 2 mapping, nor a PROT_MTE mapping in the VMM. However, the side-effect was that any page with a PTE that looked like swap (or migration) was getting PG_mte_tagged set automatically. A subsequent page copy (e.g. migration) copied the tags to the destination page even if the tags were owned by KASAN. This issue was masked by the page_kasan_tag_reset() call introduced in commit e5b8d9218951 ("arm64: mte: reset the page tag in page->flags"). When this commit was reverted (20794545c146), KASAN started reporting access faults because the overriding tags in a page did not match the original page->flags (with CONFIG_KASAN_HW_TAGS=y): BUG: KASAN: invalid-access in copy_page+0x10/0xd0 arch/arm64/lib/copy_page.S:26 Read at addr f5ff000017f2e000 by task syz-executor.1/2218 Pointer tag: [f5], memory tag: [f2] Move the PG_mte_tagged bit setting from mte_sync_tags() to the actual place where tags are cleared (mte_sync_page_tags()) or restored (mte_restore_tags()). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: syzbot+c2c79c6d6eddc5262b77@syzkaller.appspotmail.com Fixes: 69e3b846d8a7 ("arm64: mte: Sync tags for pages where PTE is untagged") Cc: <stable@vger.kernel.org> # 5.14.x Cc: Steven Price <steven.price@arm.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/0000000000004387dc05e5888ae5@google.com/ Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20221006163354.3194102-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-10-11Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds9-97/+147
Pull more kvm updates from Paolo Bonzini: "The main batch of ARM + RISC-V changes, and a few fixes and cleanups for x86 (PMU virtualization and selftests). ARM: - Fixes for single-stepping in the presence of an async exception as well as the preservation of PSTATE.SS - Better handling of AArch32 ID registers on AArch64-only systems - Fixes for the dirty-ring API, allowing it to work on architectures with relaxed memory ordering - Advertise the new kvmarm mailing list - Various minor cleanups and spelling fixes RISC-V: - Improved instruction encoding infrastructure for instructions not yet supported by binutils - Svinval support for both KVM Host and KVM Guest - Zihintpause support for KVM Guest - Zicbom support for KVM Guest - Record number of signal exits as a VCPU stat - Use generic guest entry infrastructure x86: - Misc PMU fixes and cleanups. - selftests: fixes for Hyper-V hypercall - selftests: fix nx_huge_pages_test on TDP-disabled hosts - selftests: cleanups for fix_hypercall_test" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (57 commits) riscv: select HAVE_POSIX_CPU_TIMERS_TASK_WORK RISC-V: KVM: Use generic guest entry infrastructure RISC-V: KVM: Record number of signal exits as a vCPU stat RISC-V: KVM: add __init annotation to riscv_kvm_init() RISC-V: KVM: Expose Zicbom to the guest RISC-V: KVM: Provide UAPI for Zicbom block size RISC-V: KVM: Make ISA ext mappings explicit RISC-V: KVM: Allow Guest use Zihintpause extension RISC-V: KVM: Allow Guest use Svinval extension RISC-V: KVM: Use Svinval for local TLB maintenance when available RISC-V: Probe Svinval extension form ISA string RISC-V: KVM: Change the SBI specification version to v1.0 riscv: KVM: Apply insn-def to hlv encodings riscv: KVM: Apply insn-def to hfence encodings riscv: Introduce support for defining instructions riscv: Add X register names to gpr-nums KVM: arm64: Advertise new kvmarm mailing list kvm: vmx: keep constant definition format consistent kvm: mmu: fix typos in struct kvm_arch KVM: selftests: Fix nx_huge_pages_test on TDP-disabled hosts ...
2022-10-11treewide: use get_random_{u8,u16}() when possible, part 1Jason A. Donenfeld1-1/+1
Rather than truncate a 32-bit value to a 16-bit value or an 8-bit value, simply use the get_random_{u8,u16}() functions, which are faster than wasting the additional bytes from a 32-bit value. This was done mechanically with this coccinelle script: @@ expression E; identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32"; typedef u16; typedef __be16; typedef __le16; typedef u8; @@ ( - (get_random_u32() & 0xffff) + get_random_u16() | - (get_random_u32() & 0xff) + get_random_u8() | - (get_random_u32() % 65536) + get_random_u16() | - (get_random_u32() % 256) + get_random_u8() | - (get_random_u32() >> 16) + get_random_u16() | - (get_random_u32() >> 24) + get_random_u8() | - (u16)get_random_u32() + get_random_u16() | - (u8)get_random_u32() + get_random_u8() | - (__be16)get_random_u32() + (__be16)get_random_u16() | - (__le16)get_random_u32() + (__le16)get_random_u16() | - prandom_u32_max(65536) + get_random_u16() | - prandom_u32_max(256) + get_random_u8() | - E->inet_id = get_random_u32() + E->inet_id = get_random_u16() ) @@ identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32"; typedef u16; identifier v; @@ - u16 v = get_random_u32(); + u16 v = get_random_u16(); @@ identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32"; typedef u8; identifier v; @@ - u8 v = get_random_u32(); + u8 v = get_random_u8(); @@ identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32"; typedef u16; u16 v; @@ - v = get_random_u32(); + v = get_random_u16(); @@ identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32"; typedef u8; u8 v; @@ - v = get_random_u32(); + v = get_random_u8(); // Find a potential literal @literal_mask@ expression LITERAL; type T; identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32"; position p; @@ ((T)get_random_u32()@p & (LITERAL)) // Examine limits @script:python add_one@ literal << literal_mask.LITERAL; RESULT; @@ value = None if literal.startswith('0x'): value = int(literal, 16) elif literal[0] in '123456789': value = int(literal, 10) if value is None: print("I don't know how to handle %s" % (literal)) cocci.include_match(False) elif value < 256: coccinelle.RESULT = cocci.make_ident("get_random_u8") elif value < 65536: coccinelle.RESULT = cocci.make_ident("get_random_u16") else: print("Skipping large mask of %s" % (literal)) cocci.include_match(False) // Replace the literal mask with the calculated result. @plus_one@ expression literal_mask.LITERAL; position literal_mask.p; identifier add_one.RESULT; identifier FUNC; @@ - (FUNC()@p & (LITERAL)) + (RESULT() & LITERAL) Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Yury Norov <yury.norov@gmail.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> # for sch_cake Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>