summaryrefslogtreecommitdiffstats
path: root/drivers/net/tun.c
diff options
context:
space:
mode:
authorStephan Gerhold <stephan@gerhold.net>2023-05-18 15:04:25 +0200
committerMark Brown <broonie@kernel.org>2023-05-30 13:43:31 +0100
commit0c331fd1dccfba657129380ee084b95c1cedfbef (patch)
treee1dc2b020ecad5732bc2c5ce2a047c1b1d2cafbe /drivers/net/tun.c
parent4be47a5d59cbc9396a6ffd327913eb4c8d67a32f (diff)
downloadlinux-0c331fd1dccfba657129380ee084b95c1cedfbef.tar.gz
linux-0c331fd1dccfba657129380ee084b95c1cedfbef.tar.bz2
linux-0c331fd1dccfba657129380ee084b95c1cedfbef.zip
spi: qup: Request DMA before enabling clocks
It is usually better to request all necessary resources (clocks, regulators, ...) before starting to make use of them. That way they do not change state in case one of the resources is not available yet and probe deferral (-EPROBE_DEFER) is necessary. This is particularly important for DMA channels and IOMMUs which are not enforced by fw_devlink yet (unless you use fw_devlink.strict=1). spi-qup does this in the wrong order, the clocks are enabled and disabled again when the DMA channels are not available yet. This causes issues in some cases: On most SoCs one of the SPI QUP clocks is shared with the UART controller. When using earlycon UART is actively used during boot but might not have probed yet, usually for the same reason (waiting for the DMA controller). In this case, the brief enable/disable cycle ends up gating the clock and further UART console output will halt the system completely. Avoid this by requesting the DMA channels before changing the clock state. Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230518-spi-qup-clk-defer-v1-1-f49fc9ca4e02@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'drivers/net/tun.c')
0 files changed, 0 insertions, 0 deletions