summaryrefslogtreecommitdiffstats
path: root/arch/arm64/boot
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-09Merge tag 'efi-next-for-v6.1' of ↵Linus Torvalds2-0/+7
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI updates from Ard Biesheuvel: "A bit more going on than usual in the EFI subsystem. The main driver for this has been the introduction of the LoonArch architecture last cycle, which inspired some cleanup and refactoring of the EFI code. Another driver for EFI changes this cycle and in the future is confidential compute. The LoongArch architecture does not use either struct bootparams or DT natively [yet], and so passing information between the EFI stub and the core kernel using either of those is undesirable. And in general, overloading DT has been a source of issues on arm64, so using DT for this on new architectures is a to avoid for the time being (even if we might converge on something DT based for non-x86 architectures in the future). For this reason, in addition to the patch that enables EFI boot for LoongArch, there are a number of refactoring patches applied on top of which separate the DT bits from the generic EFI stub bits. These changes are on a separate topich branch that has been shared with the LoongArch maintainers, who will include it in their pull request as well. This is not ideal, but the best way to manage the conflicts without stalling LoongArch for another cycle. Another development inspired by LoongArch is the newly added support for EFI based decompressors. Instead of adding yet another arch-specific incarnation of this pattern for LoongArch, we are introducing an EFI app based on the existing EFI libstub infrastructure that encapulates the decompression code we use on other architectures, but in a way that is fully generic. This has been developed and tested in collaboration with distro and systemd folks, who are eager to start using this for systemd-boot and also for arm64 secure boot on Fedora. Note that the EFI zimage files this introduces can also be decompressed by non-EFI bootloaders if needed, as the image header describes the location of the payload inside the image, and the type of compression that was used. (Note that Fedora's arm64 GRUB is buggy [0] so you'll need a recent version or switch to systemd-boot in order to use this.) Finally, we are adding TPM measurement of the kernel command line provided by EFI. There is an oversight in the TCG spec which results in a blind spot for command line arguments passed to loaded images, which means that either the loader or the stub needs to take the measurement. Given the combinatorial explosion I am anticipating when it comes to firmware/bootloader stacks and firmware based attestation protocols (SEV-SNP, TDX, DICE, DRTM), it is good to set a baseline now when it comes to EFI measured boot, which is that the kernel measures the initrd and command line. Intermediate loaders can measure additional assets if needed, but with the baseline in place, we can deploy measured boot in a meaningful way even if you boot into Linux straight from the EFI firmware. Summary: - implement EFI boot support for LoongArch - implement generic EFI compressed boot support for arm64, RISC-V and LoongArch, none of which implement a decompressor today - measure the kernel command line into the TPM if measured boot is in effect - refactor the EFI stub code in order to isolate DT dependencies for architectures other than x86 - avoid calling SetVirtualAddressMap() on arm64 if the configured size of the VA space guarantees that doing so is unnecessary - move some ARM specific code out of the generic EFI source files - unmap kernel code from the x86 mixed mode 1:1 page tables" * tag 'efi-next-for-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: (24 commits) efi/arm64: libstub: avoid SetVirtualAddressMap() when possible efi: zboot: create MemoryMapped() device path for the parent if needed efi: libstub: fix up the last remaining open coded boot service call efi/arm: libstub: move ARM specific code out of generic routines efi/libstub: measure EFI LoadOptions efi/libstub: refactor the initrd measuring functions efi/loongarch: libstub: remove dependency on flattened DT efi: libstub: install boot-time memory map as config table efi: libstub: remove DT dependency from generic stub efi: libstub: unify initrd loading between architectures efi: libstub: remove pointless goto kludge efi: libstub: simplify efi_get_memory_map() and struct efi_boot_memmap efi: libstub: avoid efi_get_memory_map() for allocating the virt map efi: libstub: drop pointless get_memory_map() call efi: libstub: fix type confusion for load_options_size arm64: efi: enable generic EFI compressed boot loongarch: efi: enable generic EFI compressed boot riscv: efi: enable generic EFI compressed boot efi/libstub: implement generic EFI zboot efi/libstub: move efi_system_table global var into separate object ...
2022-10-08Merge tag 'clk-for-linus' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk updates from Stephen Boyd: "We have some late breaking reports that a patch series to rework clk rate range support broke boot on some devices, so I've left that branch out of this. Hopefully we can get to that next week, or punt on it and let it bake another cycle. That means we don't really have any changes to the core framework this time around besides a few typo fixes. Instead this is all clk driver updates and fixes. The usual suspects are here (again), with Qualcomm dominating the diffstat. We look to have gained support for quite a few new Qualcomm SoCs and Dmitry worked on updating many of the existing Qualcomm drivers to use clk_parent_data. After that we have MediaTek drivers getting some much needed updates, in particular to support GPU DVFS. There are also quite a few Samsung clk driver patches, but that's mostly because there was a maintainer change and so last release we missed some of those patches. Overall things look normal, but I'm slowly reviewing core framework code nowadays and that shows given the rate range patches had to be yanked last minute. Let's hope this situation changes soon. New Drivers: - Support for Renesas VersaClock7 clock generator family - Add Spreadtrum UMS512 SoC clk support - New clock drivers for MediaTek Helio X10 MT6795 - Display clks for Qualcomm SM6115, SM8450 - GPU clks for Qualcomm SC8280XP - Qualcomm MSM8909 and SM6375 global and SMD RPM clk drivers Deleted Drivers: - Remove DaVinci DM644x and DM646x clk driver support Updates: - Convert Baikal-T1 CCU driver to platform driver - Split reset support out of primary Baikal-T1 CCU driver - Add some missing clks required for RPiVid Video Decoder on RaspberryPi - Mark PLLC critical on bcm2835 - More devm helpers for fixed rate registration - Various PXA168 clk driver fixes - Add resets for MediaTek MT8195 PCIe and USB - Miscellaneous of_node_put() fixes - Nuke dt-bindings/clk path (again) by moving headers to dt-bindings/clock - Convert gpio-clk-gate binding to YAML - Various fixes to AMD/Xilinx Zynqmp clk driver - Graduate AMD/Xilinx "clocking wizard" driver from staging - Add missing DPI1_HDMI clock in MT8195 VDOSYS1 - Clock driver changes to support GPU DVFS on MT8183, MT8192, MT8195 - Fix GPU clock topology on MT8195 - Propogate rate changes from GPU clock gate up the tree - Clock mux notifiers for GPU-related PLLs - Conversion of more "simple" drivers to mtk_clk_simple_probe() - Hook up mtk_clk_simple_remove() for "simple" MT8192 clock drivers - Fixes to previous |struct clk| to |struct clk_hw| conversion on MediaTek - Shrink MT8192 clock driver by deduplicating clock parent lists - Change order between 'sim_enet_root_clk' and 'enet_qos_root_clk' clocks for i.MX8MP - Drop unnecessary newline in i.MX8MM dt-bindings - Add more MU1 and SAI clocks dt-bindings Ids - Introduce slice busy bit check for i.MX93 composite clock - Introduce white list bit check for i.MX93 composite clock - Add new i.MX93 clock gate - Add MU1 and MU2 clocks to i.MX93 clock provider - Add SAI IPG clocks to i.MX93 clock provider - add generic clocks for U(S)ART available on SAMA5D2 SoCs - reset controller support for Polarfire clocks - .round_rate and .set rate support for clk-mpfs - code cleanup for clk-mpfs - PLL support for PolarFire SoC's Clock Conditioning Circuitry - Add watchdog, I2C, pin control/GPIO, and Ethernet clocks on R-Car V4H - Add SDHI, Timer (CMT/TMU), and SPI (MSIOF) clocks on R-Car S4-8 - Add I2C clocks and resets on RZ/V2M - Document clock support for the RZ/Five SoC - mux-variant clock using the table variant to select parents - clock controller for the rv1126 soc - conversion of rk3128 to yaml and relicensing of the yaml bindings to gpl2+MIT (following dt-binding guildelines) - Exynos7885: add FSYS, TREX and MFC clock controllers - Exynos850: add IS and AUD (audio) clock controllers with bindings - ExynosAutov9: add FSYS clock controllers with bindings - ExynosAutov9: correct clock IDs in bindings of Peric 0 and 1 clock controllers, due to duplicated entries. This is an acceptable ABI break: recently developed/added platform so without legacies, acked by known users/developers - ExynosAutov9: add few missing Peric 0/1 gates - ExynosAutov9: correct register offsets of few Peric 0/1 clocks - Minor code improvements (use of_device_get_match_data() helper, code style) - Add Krzysztof Kozlowski as co-maintainer of Samsung SoC clocks, as he already maintainers that architecture/platform - Keep Qualcomm GDSCs enabled when PWRSTS_RET flag is there, solving retention issues during suspend of USB on Qualcomm sc7180/sc7280 and SC8280XP - Qualcomm SM6115 and QCM2260 are moved to reuse PLL configuration - Qualcomm SDM660 SDCC1 moved to floor clk ops - Support for the APCS PLLs for Qualcomm IPQ8064, IPQ8074 and IPQ6018 was added/fixed - The Qualcomm MSM8996 CPU clocks are updated with support for ACD - Support for Qualcomm SDM670 GCC and RPMh clks was added - Transition to parent_data, parent_hws and use of ARRAY_SIZE() for num_parents was done for many Qualcomm SoCs - Support for per-reset defined delay on Qualcomm was introduced" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (283 commits) clk: qcom: gcc-sm6375: Ensure unsigned long type clk: qcom: gcc-sm6375: Remove unused variables clk: qcom: kpss-xcc: convert to parent data API clk: introduce (devm_)hw_register_mux_parent_data_table API clk: allow building lan966x as a module clk: clk-xgene: simplify if-if to if-else clk: ast2600: BCLK comes from EPLL clk: clocking-wizard: Depend on HAS_IOMEM clk: clocking-wizard: Use dev_err_probe() helper clk: nxp: fix typo in comment clk: pxa: add a check for the return value of kzalloc() clk: vc5: Add support for IDT/Renesas VersaClock 5P49V6975 dt-bindings: clock: vc5: Add 5P49V6975 clk: mvebu: armada-37xx-tbg: Remove the unneeded result variable clk: ti: dra7-atl: Fix reference leak in of_dra7_atl_clk_probe clk: Renesas versaclock7 ccf device driver dt-bindings: Renesas versaclock7 device tree bindings clk: ti: Balance of_node_get() calls for of_find_node_by_name() clk: imx: scu: fix memleak on platform_device_add() fails clk: vc5: Use regmap_{set,clear}_bits() where appropriate ...
2022-10-07Merge tag 'usb-6.1-rc1' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB / Thunderbolt updates from Greg KH: "Here is the big set of USB and Thunderbolt driver changes for 6.1-rc1. Nothing major in here, lots of little things with new devices supported and updates for a few drivers. Highlights include: - thunderbolt/USB4 devices supported a bit better than before, and some new ids to enable new hardware devices - USB gadget uvc updates for newer video formats and better v4l integration (the v4l portions were acked by those maintainers) - typec updates for tiny issues and more typec drivers for new chips. - xhci tiny updates for minor issues - big usb-serial ftdi_sio driver update to handle new devices better - lots of tiny dwc3 fixes and updates for the IP block that is showing up everywhere these days - dts updates for new devices being supported - other tiny janitorial and cleanups fixes for lots of different USB drivers. Full details are in the shortlog. All of these have been in linux-next for a while with no reported issues" * tag 'usb-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (169 commits) usb: gadget: uvc: don't put item still in use usb: gadget: uvc: Fix argument to sizeof() in uvc_register_video() usb: host: ehci-exynos: switch to using gpiod API Revert "usb: dwc3: Don't switch OTG -> peripheral if extcon is present" Revert "USB: fixup for merge issue with "usb: dwc3: Don't switch OTG -> peripheral if extcon is present"" dt-bindings: usb: Convert FOTG210 to dt schema usb: mtu3: fix failed runtime suspend in host only mode USB: omap_udc: Fix spelling mistake: "tranceiver_ctrl" -> "transceiver_ctrl" usb: typec: ucsi_ccg: Disable UCSI ALT support on Tegra usb: typec: Replace custom implementation of device_match_fwnode() usb: typec: ucsi: Don't warn on probe deferral usb: add quirks for Lenovo OneLink+ Dock MAINTAINERS: switch dwc3 to Thinh usb: idmouse: fix an uninit-value in idmouse_open USB: PHY: JZ4770: Switch to use dev_err_probe() helper usb: phy: generic: Switch to use dev_err_probe() helper usb: ulpi: use DEFINE_SHOW_ATTRIBUTE to simplify ulpi_regs usb: cdns3: remove dead code usb: cdc-wdm: Use skb_put_data() instead of skb_put/memcpy pair usb: musb: sunxi: Switch to use dev_err_probe() helper ...
2022-10-06Merge tag 'arm-dt-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds293-2603/+21222
Pull ARM devicetree updates from Arnd Bergmann: "Most of the changes fall into one of three categories: adding support for additional devices on existing machines, cleaning up issues found by the ongoing conversion to machine-readable bindings, and addressing minor mistakes in the existing DT data. Across SoC vendors, Qualcomm and Freescale stick out as getting the most updates, which corresponds to their dominance in the mobile phone and embedded industrial markets, respectively. There are 636 non-merge changeset in this branch, which is a little lower than most times, but more importantly we only add 36 machine files, which is about half of what we had the past few releases. Eight new SoCs are added, but all of them are variations of already supported SoC families, and most of them come with one reference board design from the SoC vendor: - Mediatek MT8186 is a Chromebook/Tablet type SoC, similar to the MT65xx series of phone SoCs, with two Cortex-A76 and six Cortex-A55 cores. - TI AM62A is another member of the K3 family with Cortex-A53 cores, this one is targetted at Video/Vision processing for industrial and automotive applications. - NXP i.MX8DXL is another chip for this market in the ever-growing i.MX8 family, this one again with two Cortex-A35 cores. - Renesas R-Car H3Ne-1.7G (R8A779MB) and R-Car V3H2 (R8A77980A) are minor updates of R8A77951 and R8A77980, respectively. - Qualcomm IPQ8064-v2.0, IPQ8062 and IPQ8065 are all variants of the IPQ8064 chip, with minimally different features. The AMD Pensando Elba and Apple M1 Ultra SoC support was getting close this time, but in the end did not make the cut. The new machines based on existing SoC support are fairly uneventful: - Sony Xperia 1 IV is a fairly recent phone based on Qualcomm Snapdragon 8 Gen 1. - Three Samsung phones based on Snapdragon 410: Galaxy E5, E7 and Grand Max. These are added for both 32-bit and 64-bit kernels, as they originally shipped running 32-bit code. - Two new servers using AST2600 BMCs: AMD DaytonaX and Ampere Mt. Mitchell - Three new machines based on Rockchips RK3399 and RK3566: Anberic RG353P and RG503, Pine64 Pinephone Pro, Open AI Lab - Multiple NXP i.MX6/i.MX8 based boards: Kontron SL/BL i.MX8MM OSM-S, i.MX8MM Gateworks GW7904, MSC SM2S-IMX8PLUS SoM and carrier board - Two development boards in the Microchip AT91 family: SAMA5D3-EDS and lan966x-pcb8290. - Minor variants of existing boards using Amlogic, Broadcom, Marvell, Rockchips, Freescale Layerscape and Socionext Uniphier SoCs" * tag 'arm-dt-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (617 commits) Revert "ARM: dts: BCM5301X: Add basic PCI controller properties" ARM: dts: s5pv210: correct double "pins" in pinmux node ARM: dts: exynos: fix polarity of VBUS GPIO of Origen arm64: dts: exynos: fix polarity of "enable" line of NFC chip in TM2 arm64: dts: uniphier: Add L2 cache node arm64: dts: uniphier: Remove compatible "snps,dw-pcie" from pcie node arm64: dts: uniphier: Fix opp-table node name for LD20 arm64: dts: uniphier: Add USB-device support for PXs3 reference board arm64: dts: uniphier: Add ahci controller nodes for PXs3 arm64: dts: uniphier: Use GIC interrupt definitions arm64: dts: uniphier: Rename gpio-hog nodes arm64: dts: uniphier: Rename usb-glue node for USB3 to usb-controller arm64: dts: uniphier: Rename usb-phy node for USB2 to usb-controller arm64: dts: uniphier: Rename pvtctl node to thermal-sensor ARM: dts: uniphier: Remove compatible "snps,dw-pcie-ep" from pcie-ep node ARM: dts: uniphier: Move interrupt-parent property to each child node in uniphier-support-card ARM: dts: uniphier: Add ahci controller nodes for PXs2 ARM: dts: uniphier: Add ahci controller nodes for Pro4 ARM: dts: uniphier: Use GIC interrupt definitions ARM: dts: uniphier: Rename gpio-hog node ...
2022-10-04Merge tag 'samsung-dt-dt64-6.1-2' of ↵Arnd Bergmann1-1/+1
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dt Samsung DTS ARM and ARM64 changes for v6.1 Late cleanup and fixes for Samsung DTS: 1. Fix polarity of pins: - enable GPIO of NFC chip in Exynos5433 TM2 boards, - vbus GPIO of EHCI in Exynos4412 Origen board. 2. Correct name of pin configuration nodes - redundant "pins" in the name (no functional impact). * tag 'samsung-dt-dt64-6.1-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: dts: s5pv210: correct double "pins" in pinmux node ARM: dts: exynos: fix polarity of VBUS GPIO of Origen arm64: dts: exynos: fix polarity of "enable" line of NFC chip in TM2 Link: https://lore.kernel.org/r/20221003073916.12588-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-09-30Merge tag 'wireless-next-2022-09-30' of ↵Jakub Kicinski6-0/+22
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.1 Few stack changes and lots of driver changes in this round. brcmfmac has more activity as usual and it gets new hardware support. ath11k improves WCN6750 support and also other smaller features. And of course changes all over. Note: in early September wireless tree was merged to wireless-next to avoid some conflicts with mac80211 patches, this shouldn't cause any problems but wanted to mention anyway. Major changes: mac80211 - refactoring and preparation for Wi-Fi 7 Multi-Link Operation (MLO) feature continues brcmfmac - support CYW43439 SDIO chipset - support BCM4378 on Apple platforms - support CYW89459 PCIe chipset rtw89 - more work to get rtw8852c supported - P2P support - support for enabling and disabling MSDU aggregation via nl80211 mt76 - tx status reporting improvements ath11k - cold boot calibration support on WCN6750 - Target Wake Time (TWT) debugfs support for STA interface - support to connect to a non-transmit MBSSID AP profile - enable remain-on-channel support on WCN6750 - implement SRAM dump debugfs interface - enable threaded NAPI on all hardware - WoW support for WCN6750 - support to provide transmit power from firmware via nl80211 - support to get power save duration for each client - spectral scan support for 160 MHz wcn36xx - add SNR from a received frame as a source of system entropy * tag 'wireless-next-2022-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (231 commits) wifi: rtl8xxxu: Improve rtl8xxxu_queue_select wifi: rtl8xxxu: Fix AIFS written to REG_EDCA_*_PARAM wifi: rtl8xxxu: gen2: Enable 40 MHz channel width wifi: rtw89: 8852b: configure DLE mem wifi: rtw89: check DLE FIFO size with reserved size wifi: rtw89: mac: correct register of report IMR wifi: rtw89: pci: set power cut closed for 8852be wifi: rtw89: pci: add to do PCI auto calibration wifi: rtw89: 8852b: implement chip_ops::{enable,disable}_bb_rf wifi: rtw89: add DMA busy checking bits to chip info wifi: rtw89: mac: define DMA channel mask to avoid unsupported channels wifi: rtw89: pci: mask out unsupported TX channels iwlegacy: Replace zero-length arrays with DECLARE_FLEX_ARRAY() helper ipw2x00: Replace zero-length array with DECLARE_FLEX_ARRAY() helper wifi: iwlwifi: Track scan_cmd allocation size explicitly brcmfmac: Remove the call to "dtim_assoc" IOVAR brcmfmac: increase dcmd maximum buffer size brcmfmac: Support 89459 pcie brcmfmac: increase default max WOWL patterns to 16 cw1200: fix incorrect check to determine if no element is found in list ... ==================== Link: https://lore.kernel.org/r/20220930150413.A7984C433D6@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-30arm64: dts: exynos: fix polarity of "enable" line of NFC chip in TM2Dmitry Torokhov1-1/+1
According to s3fwrn5 driver code the "enable" GPIO line is driven "high" when chip is not in use (mode is S3FWRN5_MODE_COLD), and is driven "low" when chip is in use. s3fwrn5_phy_power_ctrl(): ... gpio_set_value(phy->gpio_en, 1); ... if (mode != S3FWRN5_MODE_COLD) { msleep(S3FWRN5_EN_WAIT_TIME); gpio_set_value(phy->gpio_en, 0); msleep(S3FWRN5_EN_WAIT_TIME); } Therefore the line described by "en-gpios" property should be annotated as "active low". The wakeup gpio appears to have correct polarity (active high). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20220929011557.4165216-1-dmitry.torokhov@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>