IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Add initial support for the Renesas Salvator-X 2nd version development
board equipped with an R-Car M3-W+ SiP with 8 (2 x 4) GiB of RAM.
The memory map is as follows:
- Bank0: 4GiB RAM : 0x000048000000 -> 0x000bfffffff
0x000480000000 -> 0x004ffffffff
- Bank1: 4GiB RAM : 0x000600000000 -> 0x006ffffffff
Based on a patch in the BSP by Takeshi Kihara
<takeshi.kihara.df@renesas.com>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191023123342.13100-10-geert+renesas@glider.be
Add initial support for the Renesas R-Car M3-W+ (R8A77961) SoC.
This includes:
- Cortex-A57 and Cortex-A53 CPU cores
(incl. L2 caches and power state definitions),
- Power Management Unit,
- PSCI firmware,
- Pin Function Controller,
- Clock, Reset, System, and Interrupt Controllers,
- SCIF2 serial console,
- Product Register,
- ARM Architectured Timer,
and various placeholders to allow to use salvator-xs.dtsi.
Based on r8a7796.dtsi.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191023123342.13100-9-geert+renesas@glider.be
CONFIG_ARCH_R8A7796 for R-Car M3-W (R8A77960) will be renamed to
CONFIG_ARCH_R8A77960, to avoid confusion with R-Car M3-W+ (R8A77961),
which will use CONFIG_ARCH_R8A77961.
Relax dependencies by handling both symbols.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191023123342.13100-8-geert+renesas@glider.be
The Broadcom Brahma-B53 core is susceptible to the issue described by
ARM64_ERRATUM_843419 so this commit enables the workaround to be applied
when executing on that core.
Since there are now multiple entries to match, we must convert the
existing ARM64_ERRATUM_843419 into an erratum list and use
cpucap_multi_entry_cap_matches to match our entries.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Will Deacon <will@kernel.org>
Add the Brahma-B53 CPU (all versions) to the whitelists of CPUs for the
SSB and spectre v2 mitigations.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Will Deacon <will@kernel.org>
The Broadcom Brahma-B53 core is susceptible to the issue described by
ARM64_ERRATUM_845719 so this commit enables the workaround to be applied
when executing on that core.
Since there are now multiple entries to match, we must convert the
existing ARM64_ERRATUM_845719 into an erratum list.
Signed-off-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Will Deacon <will@kernel.org>
Some architectures, notably ARM, are interested in tweaking this
depending on their runtime DMA addressing limitations.
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The Emlid Neutis N5 board has AP6212 BT+WiFi chip. This patch is in
line with 8558c6e21ceb ("ARM: dts: sun8i: h3: bluetooth for Banana Pi
M2 Zero board") and other commits that add Bluetooth support for
similar boards.
Signed-off-by: Georgii Staroselskii <georgii.staroselskii@emlid.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
This patch adds the new allwinner crypto configs to ARM64 defconfig
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The Crypto Engine is a hardware cryptographic accelerator that supports
many algorithms.
This patch enables the Crypto Engine on the Allwinner H6 SoC Device-tree.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The Crypto Engine is a hardware cryptographic accelerator that supports
many algorithms.
It could be found on most Allwinner SoCs.
This patch enables the Crypto Engine on the Allwinner H5 SoC Device-tree.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The Crypto Engine is a hardware cryptographic accelerator that supports
many algorithms.
It could be found on most Allwinner SoCs.
This patch enables the Crypto Engine on the Allwinner A64 SoC Device-tree.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Now that the blkcipher algorithm type has been removed in favor of
skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher,
and rename the config options accordingly:
CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER
CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
A warning is found by the static code analysis tool:
"Identical condition 'err', second condition is always false"
Fix this by adding return value of skcipher_walk_done().
Fixes: 67cfa5d3b721 ("crypto: arm64/aes-neonbs - implement ciphertext stealing for XTS")
Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Boot failure has been reported on MSM8998 based laptop when
coresight is enabled. This is most likely due to lack of
firmware support for coresight on production device when
compared to debug device like MTP where this issue is not
observed. So disable coresight by default for MSM8998 and
enable it only for MSM8998 MTP.
Reported-and-tested-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Fixes: 783abfa2249a ("arm64: dts: qcom: msm8998: Add Coresight support")
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The retention idle state does not appear to be supported by the firmware
present on the msm8998 laptops since the state is advertised as disabled
in ACPI, and attempting to enable the state in DT is observed to result
in boot hangs. Therefore, remove the state from use to address the
observed issues.
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Fixes: 2c6d2d3a580a (arm64: dts: qcom: Add Lenovo Miix 630)
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The Kryo cores share errata 1009 with Falkor, so add their model
definitions and enable it for them as well.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[will: Update entry in silicon-errata.rst]
Signed-off-by: Will Deacon <will@kernel.org>
Enable and add supply to the Mali GPU node on all the
H6 boards.
Regarding the datasheet the maximum time for supply to reach
its voltage is 32ms.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
This patch updates device tree for RTC and PMC to allow system wake
from deep sleep on RTC alarm.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The NVIDIA Tegra210 contains an ARM PMU v3 that can be used to gather
statistics about the processors and their memory system. Add a device
tree node so that this functionality can be exposed.
Reported-by: William Cohen <giantklein@gmail.com>
Tested-by: William Cohen <giantklein@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enable both USB-C/DP ports on Jetson AGX Xavier and wire up the power
supplies for the SORs that drive these outputs.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Some of the PMIC regulators had names that don't match the schematics.
Rename them so that it is easier to cross-reference with the hardware
documentation.
Signed-off-by: Thierry Reding <treding@nvidia.com>
It turns out that both SORs on Tegra186 are the same, so there's no need
to distinguish between them in the compatible string.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the AVDD_IO_EDP_1V05 and enable the SOR and DPAUX hardware blocks
that are used to drive DisplayPort on Jetson Nano.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This clock was not previously used because it is a fixed clock. However,
adding it here allows operating systems to deal with SOR0 the same way
as SOR1.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Although Tegra194 has support for CLKREQ sideband signal and P2972
has routing of the same till the slot, it is the case most of the time
that the connected device doesn't have CLKREQ support. Hence, it makes
sense to assume that there is no CLKREQ support by default and it can
be enabled on need basis when a card with CLKREQ support is connected.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This enables the use of the USB ports found on the Jetson TX2 for input
or external storage, for example.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enabling the SMMU for XUSB host allows buffers to be mapped through the
ARM SMMU, which helps protecting the system from rogue memory accesses
by the XUSB host.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The XUSB pad controller is a prerequisite for enabling XUSB support.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra194 EQOS controller is used as primary Ethernet interface.
Set the ethernet0 alias to reflect that.
Generic bootloader code can use this to find the primary Ethernet device
and set the MAC address, for example.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The EQOS Ethernet controller found on Tegra194 is compatible with its
predecessor or Tegra186. However, it is an established practice to add
a compatible string for the most recent generation of the SoC as well,
just in case some incompatibilities or bugs are later discovered.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The SOR1 hardware block's registers start at physical address 0x15b40000
as correctly specified by the unit-address, but the reg property lists a
wrong value, likely because it was copy-and-pasted from SOR0 but not
correctly updated.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The ACONNECT complex starts at physical address 0x2900000, so give it a
unit-address to comply with standard naming practices checked for by the
device tree compiler.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The control back-bone (CBB) starts at physical address 0, so give it a
unit-address to comply with standard naming practices checked for by the
device tree compiler.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra194 has four CPU clusters, each with their own cache hierarchy.
This patch creates the CPU map for these clusters and adds the second-
and third-level caches and associates them with the CPUs.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commit 4fdbfd60a3a2 ("arm64: tegra: Add PCIe slot supply information
in p2972-0000 platform") added regulators for the PCIe slot on the
Jetson Xavier platform. One of these regulators has an active-low enable
and this commit incorrectly added an active-low specifier for the GPIO
which causes the following warning to occur on boot ...
WARNING KERN regulator@3 GPIO handle specifies active low - ignored
The fixed-regulator binding does not use the active-low flag from the
gpio specifier and purely relies of the presence of the
'enable-active-high' property to determine if it is active high or low
(if this property is omitted). Fix this warning by setting the GPIO
to active-high in the GPIO specifier. Finally, remove the
'enable-active-low' as this is not a valid property.
Fixes: 4fdbfd60a3a2 ("arm64: tegra: Add PCIe slot supply information in p2972-0000 platform")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commit 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1")
added a regulator for HDMI on the Jetson TX1 platform. This regulator
has an active high enable, but the GPIO specifier for enabling the
regulator incorrectly defines it as active-low. This causes the
following warning to occur on boot ...
WARNING KERN regulator@10 GPIO handle specifies active low - ignored
The fixed-regulator binding does not use the active-low flag from the
gpio specifier and purely relies of the presence of the
'enable-active-high' property to determine if it is active high or low
(if this property is omitted). Fix this warning by setting the GPIO
to active-high in the GPIO specifier which aligns with the presense of
the 'enable-active-high' property.
Fixes: 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
With the introduction of 'cce360b54ce6 ("arm64: capabilities: Filter the
entries based on a given mask")' the Qualcomm Falkor/Kryo errata 1003 is
no long applied.
The result of not applying errata 1003 is that MSM8996 runs into various
RCU stalls and fails to boot most of the times.
Give 1003 a "type" to ensure they are not filtered out in
update_cpu_capabilities().
Fixes: cce360b54ce6 ("arm64: capabilities: Filter the entries based on a given mask")
Cc: stable@vger.kernel.org
Reported-by: Mark Brown <broonie@kernel.org>
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Shared and writable mappings (__S.1.) should be clean (!dirty) initially
and made dirty on a subsequent write either through the hardware DBM
(dirty bit management) mechanism or through a write page fault. A clean
pte for the arm64 kernel is one that has PTE_RDONLY set and PTE_DIRTY
clear.
The PAGE_SHARED{,_EXEC} attributes have PTE_WRITE set (PTE_DBM) and
PTE_DIRTY clear. Prior to commit 73e86cb03cf2 ("arm64: Move PTE_RDONLY
bit handling out of set_pte_at()"), it was the responsibility of
set_pte_at() to set the PTE_RDONLY bit and mark the pte clean if the
software PTE_DIRTY bit was not set. However, the above commit removed
the pte_sw_dirty() check and the subsequent setting of PTE_RDONLY in
set_pte_at() while leaving the PAGE_SHARED{,_EXEC} definitions
unchanged. The result is that shared+writable mappings are now dirty by
default
Fix the above by explicitly setting PTE_RDONLY in PAGE_SHARED{,_EXEC}.
In addition, remove the superfluous PTE_DIRTY bit from the kernel PROT_*
attributes.
Fixes: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()")
Cc: <stable@vger.kernel.org> # 4.14.x-
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
When attempting to executing non-executable memory, the fault message
shows:
Unable to handle kernel read from unreadable memory at virtual address
ffff802dac469000
This may confuse someone, so add a new fault message for instruction
abort.
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Xiang Zheng <zhengxiang9@huawei.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
