Remove default optee node in SoC core devicetree because optee
is not an inherent component in SoC.
Add optee node to supply OP-TEE required properties for Android
products which need OP-TEE enable default.
Change-Id: I0754a3498c5e6d7b7db57bb35c42c3875afd27c9
Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
The SPDIF receiver is a self-clocking, serial, unidirectional
interface for the interconnection of digital audio equipment
for consumer and professional applications.
Change-Id: Ic73337671b37c8c45352e523a875281edd552d1b
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
This patch add vbus regulator and fusb302 nodes for
rk3588 and rk3588s evbs, and also disable unused usb
controllers and phys node.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: I59678e7cd34de76ed09cc55010a1d8533fe58602
The pcie supply design is (rk3566 evb2 example)
DC12V
-> VCC12V_PCIE(controlled by GPIO0_C2_H)
-> VCC3V3_PCIE(controlled by GPIO0_C2_H)
-> VCC5V0_SYS
-> VCC3V3_PI6C(controlled by GPIO0_C2_H)
The pci phy driver only want to enable or disable the VCC3V3_PCIE power.
Suggested from pcie owner to ignore the VCC12V_PCIE and VCC3V3_PI6C, so
the dts only need to add regulator node for VCC3V3_PCIE.
Most of time we keep the regulator name same as the hardware design, so
the dts node is
vcc3v3_pcie: gpio-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc3v3_pcie";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
enable-active-high;
gpio = <&gpio0 RK_PB7 GPIO_ACTIVE_HIGH>;
vin-supply = <&dc_12v>;
};
The regulator type is "regulator-fixed" since its voltage always be
3.3v, min and max should be 3300000 make the regulator has a voltage
value.
The regulator can be enabled or disabled by regulator_enable or
regulator_disable function, so make the GPIO0_B7 as "ena_pin" for the
regulator.
The regulator is supplied by DCIN_12V, so add the vin-supply.
Some boards need a delay before enabling trainning for power to be
stable from the measurement.
By measurement, 5ms is enough for power and refclk to be stable.
Change-Id: Iaf70abe9c9e06504af067dc0e3d60b775557c026
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
v2 tuning has a defect that if invalid space is laid
between 90 and 180, and the PVT might make the invalid
space back and forth. To overcome this weakness, we don't
need to select phase from beginning, and should directly
chose the next one against the last phase selected.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Change-Id: I0cbeb1dba524c2e23a3719d28b868af3ed49e20b
SPF patchset introduced an mmu_notifier imbalance by adding a new exit
path that skips mmu_notifier_invalidate_range_only_end after calling
mmu_notifier_invalidate_range_start. This triggers a BUG in KVM driver
checking for mmu_notifier_count to remain balanced
Fixes: afeec97a8d ("FROMLIST: mm: prepare for FAULT_FLAG_SPECULATIVE")
Bug: 161210518
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ibe9d1f0903a23b48c9d733b81249b190e5321c2f
These controllers only have playback or capture capability.
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Change-Id: I69791088e4fd3e9a623b938279a7580b928dc89a
This patch add support for rk3588 pdm which is the same
with rv1126.
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Change-Id: I5df248970c9fdfd27e048cc1a6bb60898c50e8f3
This patch adds support for rk3588 spdif which is the same
with rk3366.
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Change-Id: Ia6677fc9281868edd9960337aa9726b36b754e3e
the name is consistent with the schematic diagram of the hardware.
Signed-off-by: shengfei Xu <xsf@rock-chips.com>
Change-Id: I97c7bebcf1358e461ab37846e0b0034483e20760
Add min/max voltage for usb regulators, also add vin-supply for them.
From rk3568-evb1 hardware design, the power tree about usb is
DC12V
-> VCC5V0_USB(controlled by EXT_EN from PMIC)
-> VCC5V0_HOST(controlled by GPIO0_A6)
-> VCC5V0_OTG(controlled by GPIO0_A5)
The EXT_EN from PMIC RK809 is designed for device power off to cut off
the usb 5.0v power, during system on, it keeps always on.
Change-Id: I21e431b4b41022b101b6db92b0769d096679b67c
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
fix NULL Pointer when isp to reset
[ 4486.719609] __iommu_dma_unmap+0x14/0x7c
[ 4486.719968] iommu_dma_unmap_sg+0x64/0x90
[ 4486.720348] __iommu_unmap_sg_attrs+0x48/0x5c
[ 4486.720745] vb2_dma_sg_dmabuf_ops_detach+0x60/0x80
[ 4486.721192] dma_buf_detach+0x88/0x9c
iommu_detach_device will set domain to null,
and __iommu_dma_unmap using domain but no check.
Change-Id: I3c679565c6a7e67783e1750fc4d028191a9c9fcf
Signed-off-by: Cai YiWei <cyw@rock-chips.com>
FIPS 140-3 requires this for some reason.
Bug: 188620248
Change-Id: I7c286532097e1d8971faf4d8be31b801f9007e3b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit c14d52059b)
The lab has confirmed that it is actually fine for users to keep using
non-FIPS code after the module has loaded if they were already using it
beforehand. So remove the code that tried to prevent this by updating
live algorithms in-place. Similarly, remove the call to
synchronize_rcu_tasks() which no longer has any purpose.
We still need to move the live algorithms to a private list, so keep
doing that. Keep appending "+orig" to cra_name as well, and start doing
the same for cra_driver_name too.
Bug: 188620248
Change-Id: I29c9faec7d7314484a03f9729924b2f892552c7c
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 54aecb72db)
As per the new guidance from the lab, the module must block crypto
operations until the tests have completed. It's unclear what this means
exactly (given that technically this is impossible), but let's make some
changes that should be enough to comply with the requirement's intent.
First, register the library functions and update the live algorithms
after the tests rather than before the tests. This is a trivial change.
Much more problematic is the fact that the algorithms are registered
with the kernel's crypto framework before the tests run, as the tests
depend on the framework. Unfortunately, the lab believes that the
kernel isn't allowed to enforce the ordering here; the module itself
must. Moreover, trying to solve this by copying the crypto API
framework into the module proved to be heavily problematic.
Thus, implement an alternate solution: make the module override the tfm
initialization function of every algorithm it registers, so that it can
wait for the tests to complete before allowing the use of any algorithm.
This is sufficient if the user makes a supported sequence of API calls.
Bug: 153614920
Bug: 188620248
Change-Id: I11ffba90c08114dda4e91c4be7ce8b608c4e14c1
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 02e48f383b)
Instead of having a special case in the core kernel's module loader that
treats a module called 'fips140.ko' in a special way, use a host tool to
tweak the ELF metadata of this module so that the RELA data is preserved
and accessible to the module init code.
This is done in the following way:
- each RELA section that we care about (the ones for .text and .rodata
at the moment) is copied into a new section called .init.rela.<name>
with the SHF_ALLOC attribute, so that the module loader will copy it
into __init memory at load time;
- for each such section, an offset/count tuple is added as a global
variable to the module;
- the count field of those tuples is populated directly by the host tool
based on the actual size of the RELA section in question;
- the offset field is decorated with a place-relative relocation against
the start of the copied RELA section via a weak symbol reference,
which causes an entry to be emitted into the ELF symbol table;
- these ELF symbol table entries are updated by the host tool and turned
into STT_SECTION type symbols with STB_GLOBAL linkage, carrying the
correct section index.
With these changes in place, the unmodified module loader will load all
required information into memory in a way that permits the module init
code to locate the relocations, and apply them in reverse.
Bug: 153614920
Bug: 188620248
Change-Id: I07d9704febdf913834502dd09c19aa4a04d983b1
Signed-off-by: Ard Biesheuvel <ardb@google.com>
(cherry picked from commit 502af6e349)
We currently only emit directives for handling the .text section into
the module linker script if both LTO and CFI are enabled, while for
other sections, we do this even if CFI is not enabled. This is
inconsistent at best, but as it also interferes with the assumption in
the fips140.ko module that the .text._start and .text._end input
sections are placed at the very start and end of the .text section,
which currently can only be relied upon if CFI is enabled.
So rearrange the #ifdef so that it only covers the .text.__cfi_check
input section. Note that aligning to page size is likely to be redundant
in any case, given that the .text section is laid out first, and module
allocations are page aligned to begin with, so making that part
unconditional is unlikely to make an observeable difference in the
output.
Bug: 153614920
Bug: 188620248
Fixes: 6be141eb36 ("ANDROID: crypto: fips140 - perform load time integrity check")
Change-Id: I3f9ed0ae8fa8fe5693c8d2964566cbb42c101aa7
Signed-off-by: Ard Biesheuvel <ardb@google.com>
(cherry picked from commit 6ae8277450)
These flags are supposed to be used when building all source files for
the module.
Bug: 188620248
Fixes: b7397e89db ("ANDROID: fips140: add power-up cryptographic self-tests")
Change-Id: I41cacff040c8a8a0065dd3cfc537303f1ff18335
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 422bc2feb7)
Unfortunately, the AES-GCM implementations won't actually be able to be
FIPS-approved. One consequence of this is that the "cmac" template will
need to be tested with all underlying "aes" implementations, as the
equivalent test with "gcm" won't count as fulfilling the requirement to
test all AES implementations in an authenticated mode when supported.
Update the self-tests and comments accordingly.
Bug: 153614920
Bug: 188620248
Change-Id: I874b0718a5ff9d4e2dea2353448266e87f3f0d0b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit a9765fb6dc)
Although jitterentropy doesn't necessarily need to be part of
fips140.ko, it does need to have the SP800-90B health tests enabled, and
that requires that it be compiled with the fips_enabled flag set. The
easiest way to do this is just to include a copy of it in fips140.ko.
Bug: 153614920
Bug: 188620248
Change-Id: I9dc0281e07e08e0650e3d340897c697722ad3b1a
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit cae2421105)
AES-CMAC is a FIPS allowed algorithm, and fips140.ko already has
arm64 implementations of it. Meanwhile, GKI includes both these arm64
implementations as well as the "cmac" template. Add the "cmac" template
to fips140.ko too and add a self-test for AES-CMAC, so that we can
include AES-CMAC in the set of algorithms which will be certified.
As with a number of the other algorithms, the criteria for which
algorithms need to be in the certified set are still not particularly
clear, but the latest guidance we've received is to error on the side of
including algorithms.
Bug: 153614920
Bug: 188620248
Change-Id: I6c1d9281fe848a7101d5ef94ab48e5a41bbcc6f8
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 038dc9f2cc)
AES-CBC-CTS is a FIPS allowed algorithm, and fips140.ko already has
arm64 implementations of it. Meanwhile, GKI includes both these arm64
implementations as well as the "cts" template. Add the "cts" template
to fips140.ko too and add a self-test for AES-CBC-CTS, so that we can
include AES-CBC-CTS in the set of algorithms which will be certified.
There appears to be no support for CBC-CTS mode in pycryptodome or
python-cryptography, so I manually added the test vector.
As with a number of the other algorithms, the criteria for which
algorithms need to be in the certified set are still not particularly
clear, but the latest guidance we've received is to error on the side of
including algorithms. Android uses AES-CBC-CTS for filenames
encryption, which may be relevant (though arguably this use case doesn't
actually require a FIPS approved algorithm).
Bug: 153614920
Bug: 188620248
Change-Id: I53ffbd1d38493592eeaf471bc0007978ec400878
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit e2cfdfbc51)
The lab has confirmed that this test is not required.
Bug: 153614920
Bug: 188620248
Change-Id: Ie55031beacd00f093db3a7ba30fe0844a2ce363b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit ea902862ea)
By using the initial_value parameter when creating the pycryptodome
AES-CTR instance, we can use any 16-byte IV, like the other AES modes.
Therefore, there's no need for the last 4 bytes of the IV to be 0.
This doesn't really matter, but it seems nice to avoid this quirk.
Bug: 153614920
Bug: 188620248
Change-Id: If33de260b1119f2b3e004164199b08364781ab23
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit fa5a44b364)
Test all implementations of each algorithm rather than just the highest
priority implementation. This aligns with the revised guidance we have
received from the lab.
We can still skip some tests in some cases, as per the FIPS 140-2
Implementation Guidance document. See the comments for details.
To align with the new scope of the tests, the fips140.broken_alg module
parameter now must specify an implementation (e.g. "sha256-ce") rather
than an algorithm (e.g. "sha256").
No change to the DRBG tests is required, as it turns out the module only
includes HMAC_DRBG. However, clarify the comment about the DRBG tests.
On a Pixel device, this increases the running time of the fips140 tests
from 0.5ms to 3.1 ms (very roughly; there's a lot of variation). This
is still very fast, so it isn't expected to be a problem.
Bug: 153614920
Bug: 173104584
Bug: 188620248
Change-Id: I555b535dd45f0164b7744a2c9338c501bb88de86
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit abe0780696)
dpcm_end_walk_at_be() stops the graph walk when first BE is found for
the given FE component. In a component model we may want to connect
multiple DAIs from different components.
android_vh_snd_soc_card_get_comp_chain can be registered here
to allows DAI/component chaining.
Later PCM operations can be called for all these listed components for a
valid DAPM path.
ALSA machine driver can setup component_chaining like below code slice.
static void my_board_component_chaining_hook(void *data, bool *ret)
{
*ret = true;
}
static int my_board_dev_probe(struct platform_device *pdev)
{
register_trace_android_vh_snd_soc_card_get_comp_chain(
my_board_component_chaining_hook, NULL);
return 0;
}
static int my_board_dev_remove(struct platform_device *pdev)
{
unregister_trace_android_vh_snd_soc_card_get_comp_chain(
my_board_component_chaining_hook, NULL);
return 0;
}
static struct platform_driver my_board_driver = {
...
.probe = my_board_dev_probe,
.remove = my_board_dev_remove,
...
};
Bug: 198732156
Signed-off-by: Bicycle Tsai <bicycle.tsai@mediatek.com>
Change-Id: Ife5df291d40af9ec83d57462b6a08aba95d9119d
