Since commit 93d2e4322a ("of: platform: Batch fwnode parsing when
adding all top level devices") was added, the probing of the Tegra
SRAM device has occurred later in the boot sequence, after the BPMP
has been probed. The BPMP uses sections of the SRAM for shared memory
and if the BPMP is probed before the SRAM then it fails to probe and
never tries again. This is causing a boot failure on Tegra186 and
Tegra194. Fix this by allowing the probe of the BPMP to be deferred if
the SRAM is not available yet.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commit f2ae97062a ("firmware: smccc: Refactor SMCCC specific bits into
separate file") introduced the following build warning:
drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for
function 'arm_smccc_version_init' [-Wmissing-prototypes]
void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
^~~~~~~~~~~~~~~~~~~~~~
Fix the same by adding the missing prototype in arm-smccc.h
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20200521110836.57252-1-sudeep.holla@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
For backward compatibility reasons, PSCI maintains SMCCC version as
SMCCC didn't provide ARM_SMCCC_VERSION_FUNC_ID until v1.1.
PSCI initialises both the SMCCC version and conduit. Similar to the
conduit, let us provide accessors to fetch the SMCCC version also so
that other SMCCC v1.1+ features can use it.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Etienne Carriere <etienne.carriere@st.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20200518091222.27467-7-sudeep.holla@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
In order to add newer SMCCC v1.1+ functionality and to avoid cluttering
PSCI firmware driver with SMCCC bits, let us move the SMCCC specific
details under drivers/firmware/smccc/smccc.c
We can also drop conduit and smccc_version from psci_operations structure
as SMCCC was the sole user and now it maintains those.
No functionality change in this patch though.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Etienne Carriere <etienne.carriere@st.com>
Reviewed-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20200518091222.27467-6-sudeep.holla@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Instead of maintaining 2 sets of enums/macros for tracking SMCCC version,
let us drop smccc_version enum and use ARM_SMCCC_VERSION_1_x directly
instead.
This is in preparation to drop smccc_version here and move it separately
under drivers/firmware/smccc.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Etienne Carriere <etienne.carriere@st.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20200518091222.27467-5-sudeep.holla@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
SMCCC v1.0 lacked discoverability of version and features. To accelerate
adoption of few mitigations and protect systems more rapidly from various
vulnerability, PSCI v1.0 was updated to add SMCCC discovery mechanism
though the PSCI firmware implementation of PSCI_FEATURES(SMCCC_VERSION)
which returns success on firmware compliant to SMCCC v1.1 and above.
This inturn makes SMCCC v1.1 and above dependent on ARM_PSCI_FW for
backward compatibility. Let us introduce a new hidden config for the
same to build more features on top of SMCCC v1.1 and above.
While at it, also sort alphabetically the psci entry.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Etienne Carriere <etienne.carriere@st.com>
Reviewed-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20200518091222.27467-2-sudeep.holla@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Now we can use snprintf to do the UTF-16 to UTF-8 translation for the
command line.
Drop the special "zero" trick to handle an empty command line. This was
unnecessary even before this since with options_chars == 0,
efi_utf16_to_utf8 would not have accessed options at all. snprintf won't
access it either with a precision of 0.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-25-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
efi_convert_cmdline currently overestimates the length of the equivalent
UTF-8 encoding.
snprintf can now be used to do the conversion to UTF-8, however, it does
not have a way to specify the size of the UTF-16 string, only the size
of the resulting UTF-8 string. So in order to use it, we need to
precalculate the exact UTF-8 size.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-24-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
efi_printk can now handle the UTF-16 filename, so print it using efi_err
instead of a separate efi_char16_puts call.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-23-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
In order to be able to use the UTF-16 support added to vsprintf in the
previous commit, enhance efi_puts to decode UTF-8 into UTF-16. Invalid
UTF-8 encodings are passed through unchanged.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-22-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Add the required typedefs etc for using con_in's simple text input
protocol, and for using the boottime event services.
Also add the prototype for the "stall" boot service.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-19-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Use the efi_printk function in efi_info/efi_err, and add efi_debug. This
allows formatted output at different log levels.
Add the notion of a loglevel instead of just quiet/not-quiet, and
parse the efi=debug kernel parameter in addition to quiet.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200520170223.GA3333632@rani.riverdale.lan/
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Use %ptT instead of open coded variant to print content of
time64_t type in human readable format.
Link: https://lore.kernel.org/r/20200415170046.33374-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Rewieved-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
The SDEI handler save/restores the addr_limit using set_fs(). It isn't
very clear why. The reason is to mirror the arch code's entry assembly.
The arch code does this because perf may access user-space, and
inheriting the addr_limit may be a problem.
Add a comment explaining why this is here.
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=822
Link: https://lore.kernel.org/r/20200519182108.13693-4-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
'chan_name' is malloced in imx_scu_probe() and should be freed
before leaving from the error handling cases, otherwise it will
cause memory leak.
Fixes: edbee095fa ("firmware: imx: add SCU firmware driver support")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The decompressor can load from anywhere in memory, and the only reason
the EFI stub code relocates it is to ensure it appears within the first
128 MiB of memory, so that the uncompressed kernel ends up at the right
offset in memory.
We can short circuit this, and simply jump into the decompressor startup
code at the point where it knows where the base of memory lives. This
also means there is no need to disable the MMU and caches, create new
page tables and re-enable them.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
If we get an invalid conversion specifier, bail out instead of trying to
fix it up. The format string likely has a typo or assumed we support
something that we don't, in either case the remaining arguments won't
match up with the remaining format string.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-16-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Consolidate the actual output of the formatted text into one place.
Fix a couple of edge cases:
1. If 0 is printed with a precision of 0, the printf specification says
that nothing should be output, with one exception (2b).
2. The specification for octal alternate format (%#o) adds the leading
zero not as a prefix as the 0x for hexadecimal is, but by increasing
the precision if necessary to add the zero. This means that
a. %#.2o turns 8 into "010", but 1 into "01" rather than "001".
b. %#.o prints 0 as "0" rather than "", unlike the situation for
decimal, hexadecimal and regular octal format, which all output an
empty string.
Reduce the space allocated for printing a number to the maximum actually
required (22 bytes for a 64-bit number in octal), instead of the 66
bytes previously allocated.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-15-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
A negative precision should be ignored completely, and the presence of a
valid precision should turn off the 0 flag.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-10-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Move flags parsing code out into a helper function.
The '%%' case can be handled up front: it is not allowed to have flags,
width etc.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-9-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Support 'll' qualifier for long long by copying the decimal printing
code from lib/vsprintf.c. For simplicity, the 32-bit code is used on
64-bit architectures as well.
Support 'hh' qualifier for signed/unsigned char type integers.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-8-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reclaim the bloat from the addition of printf by optimizing the stub for
size. With gcc 9, the text size of the stub is:
ARCH before +printf -Os
arm 35197 37889 34638
arm64 34883 38159 34479
i386 18571 21657 17025
x86_64 25677 29328 22144
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-6-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Copy vsprintf from arch/x86/boot/printf.c to get a simple printf
implementation.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-5-nivedita@alum.mit.edu
[ardb: add some missing braces in if...else clauses]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Use a buffer to convert the string to UTF-16. This will reduce the
number of firmware calls required to print the string from one per
character to one per string in most cases.
Cast the input char to unsigned char before converting to efi_char16_t
to avoid sign-extension in case there are any non-ASCII characters in
the input.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-4-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
These functions do not support formatting, unlike printk. Rename them to
puts to make that clear.
Move the implementations of these two functions next to each other.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-3-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Add #include directives for include files that efistub.h depends on,
instead of relying on them having been included by the C source files
prior to efistub.h.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200518190716.751506-2-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This fixes the boot issues since 5.3 on several Dell models when the TPM
is enabled. Depending on the exact grub binary, booting the kernel would
freeze early, or just report an error parsing the final events log.
We get an event log in the SHA-1 format, which doesn't have a
tcg_efi_specid_event_head in the first event, and there is a final events
table which doesn't match the crypto agile format.
__calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and
either fails, or loops long enough for the machine to be appear frozen.
So we now only parse the final events table, which is per the spec always
supposed to be in the crypto agile format, when we got a event log in this
format.
Fixes: c46f340569 ("tpm: Reserve the TPM final events table")
Fixes: 166a2809d6 ("tpm: Don't duplicate events from the final event log in the TCG2 log")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611
Signed-off-by: Loïc Yhuel <loic.yhuel@gmail.com>
Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yhuel@gmail.com
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: Matthew Garrett <mjg59@google.com>
[ardb: warn when final events table is missing or in the wrong format]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Pull up arch-specific prototype efi_systab_show_arch() in order to
fix a -Wmissing-prototypes warning:
arch/x86/platform/efi/efi.c:957:7: warning: no previous prototype for
‘efi_systab_show_arch’ [-Wmissing-prototypes]
char *efi_systab_show_arch(char *str)
Signed-off-by: Benjamin Thiel <b.thiel@posteo.de>
Link: https://lore.kernel.org/r/20200516132647.14568-1-b.thiel@posteo.de
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This contains core changes needed for the CPU frequency scaling and CPU
idle drivers on Tegra20 and Tegra30.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAl6+pNMTHHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zoYq9EACR0PciY3lTiQdmNqUGqEXp044Fg9CE
CpnjcyJh9a+3wzwtx8ZjEng7KhwUyj3trKW6gpazjaNFTzNgOqVoYEZIetOJIc5u
ZHFF7OYr+ZO5xmy4jYRuj6ZHSznn7ImrLLL8JVuYQHFHgxTlM1enSCRG3HN7Z2c7
MUmM9wnio0amREKZXgnSkN87OO1r8kaKqWFUjwqs6K8j5NvTGVYW+5YIf4Zlc7PB
5yKTt2EdPx1LpoVA+b8K/sRe8rNDwC4vxuVoDpXzBvM0s2kMIy+tIEx1plQLwkDV
dHSMT8sk6XD9yVAuzEqai341w5dm02GTfKvSy/gLoZ2NTshF99CnpLaUd3aicq/n
/9lkRtxYtb8uvlB+vKlv/LaUsDqA6casXXKstpGTUD5Oc2pSsXNGGTBhGfqwNO+v
VLNPNYLDKZbXx4HEhn7vH0c43WXTD8ydxa91HZf1GcL6hcrnklI/rbnX7QCKuVzc
IsYZPfQ1YclvaoC4wRMBhR5Hj3AW7l3N2k5oTPD+F8cIfxF5e+eELYdGOvs27ncM
SnaNve9x1IOAZmCKEQhxQorjT1nDSDd7quasXQ9nzx7bTgIa7H+QsFOYkrIPLNHi
ld7TpnK6/M4b6gaXqb6rvWnYKHTfNuP59843AUQafpnWhYHZJvrjg6n6XJNUe5g6
bvXlQIbx/fhfdQ==
=7XEQ
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-5.8-arm-core' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/soc
ARM: tegra: Core changes for v5.8-rc1
This contains core changes needed for the CPU frequency scaling and CPU
idle drivers on Tegra20 and Tegra30.
* tag 'tegra-for-5.8-arm-core' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
ARM: tegra: Create tegra20-cpufreq platform device on Tegra30
ARM: tegra: Don't enable PLLX while resuming from LP1 on Tegra30
ARM: tegra: Switch CPU to PLLP on resume from LP1 on Tegra30/114/124
ARM: tegra: Correct PL310 Auxiliary Control Register initialization
ARM: tegra: Do not fully reinitialize L2 on resume
ARM: tegra: Initialize r0 register for firmware wake-up
firmware: tf: Different way of L2 cache enabling after LP2 suspend
firmware: tegra: Make BPMP a regular driver
Link: https://lore.kernel.org/r/20200515145311.1580134-10-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Shadow stacks are not available in the EFI stub, filter out SCS flags.
Suggested-by: James Morse <james.morse@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
If 'mfd_add_devices()' fails, we must undo 'zynqmp_pm_api_debugfs_init()'
otherwise some debugfs directory and files will be left.
Just move the call to 'zynqmp_pm_api_debugfs_init()' a few lines below to
fix the issue.
Fixes: e23d9c6d0d ("drivers: soc: xilinx: Add ZynqMP power domain driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Jolly Shah <jolly.shah@xilinx.com>
Link: https://lore.kernel.org/r/20200510130357.233364-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
While debugging a boot failure, the following unknown error record was
seen in the boot logs.
<...>
BERT: Error records from previous boot:
[Hardware Error]: event severity: fatal
[Hardware Error]: Error 0, type: fatal
[Hardware Error]: section type: unknown, 81212a96-09ed-4996-9471-8d729c8e69ed
[Hardware Error]: section length: 0x290
[Hardware Error]: 00000000: 00000001 00000000 00000000 00020002 ................
[Hardware Error]: 00000010: 00020002 0000001f 00000320 00000000 ........ .......
[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
[Hardware Error]: 00000030: 00000000 00000000 00000000 00000000 ................
<...>
On further investigation, it was found that the error record with
UUID (81212a96-09ed-4996-9471-8d729c8e69ed) has been defined in the
UEFI Specification at least since v2.4 and has recently had additional
fields defined in v2.7 Section N.2.10 Firmware Error Record Reference.
Add support for parsing and printing the defined fields to give users
a chance to figure out what went wrong.
Signed-off-by: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: linux-acpi@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Link: https://lore.kernel.org/r/20200512045502.3810339-1-punit1.agrawal@toshiba.co.jp
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
In allocate_e820(), call the EFI get_memory_map() service directly
instead of indirectly via efi_get_memory_map(). This avoids allocation
of a buffer and return of the full EFI memory map, which is not needed
here and would otherwise need to be freed.
Routine allocate_e820() only needs to know how many EFI memory
descriptors there are in the map to allocate an adequately sized
e820ext buffer, if it's needed. Note that since efi_get_memory_map()
returns a memory map buffer sized with extra headroom, allocate_e820()
now needs to explicitly factor that into the e820ext size calculation.
Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
loaded directly from an EEPROM or, if not present, by the SoC's
VideoCore. Inform VideoCore that VL805 was just reset.
Also, as this creates a dependency between USB_PCI and VideoCore's
firmware interface, and since USB_PCI can't be set as a module neither
this can. Reflect that on the firmware interface Kconfg.
Link: https://lore.kernel.org/r/20200505161318.26200-5-nsaenzjulienne@suse.de
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip
that implements xHCI. After a PCI reset, VL805's firmware may either be
loaded directly from an EEPROM or, if not present, by the SoC's
co-processor, VideoCore. RPi4's VideoCore OS contains both the non public
firmware load logic and the VL805 firmware blob. The function this patch
introduces triggers the aforementioned process.
Link: https://lore.kernel.org/r/20200505161318.26200-3-nsaenzjulienne@suse.de
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
i.MX8 SoCs DTS file needs system control macro definitions, so move them
into dt-binding headfile, then include/linux/firmware/imx/types.h can be
removed and those drivers using it should be changed accordingly.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200508210805.GA24170@embeddedor
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
When I play with terminus fonts I noticed the efi early printk does
not work because the earlycon code assumes font width is 8.
Here add the code to adapt with larger fonts. Tested with all kinds
of kernel built-in fonts on my laptop. Also tested with a local draft
patch for 14x28 !bold terminus font.
Signed-off-by: Dave Young <dyoung@redhat.com>
Link: https://lore.kernel.org/r/20200412024927.GA6884@dhcp-128-65.nay.redhat.com
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
It seems that for whatever reason, gcc-10 ends up not inlining a couple
of functions that used to be inlined before. Even if they only have one
single callsite - it looks like gcc may have decided that the code was
unlikely, and not worth inlining.
The code generation difference is harmless, but caused a few new section
mismatch errors, since the (now no longer inlined) function wasn't in
the __init section, but called other init functions:
Section mismatch in reference from the function kexec_free_initrd() to the function .init.text:free_initrd_mem()
Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memremap()
Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memunmap()
So add the appropriate __init annotation to make modpost not complain.
In both cases there were trivially just a single callsite from another
__init function.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When CONFIG_ARM_PSCI_FW is disabled but CONFIG_HAVE_ARM_SMCCC is enabled,
arm-scmi runs into a link failure:
arm-linux-gnueabi-ld: drivers/firmware/arm_scmi/smc.o: in function `smc_send_message':
smc.c:(.text+0x200): undefined reference to `arm_smccc_1_1_get_conduit'
Change from HAVE_ARM_SMCCC to ARM_PSCI_FW config dependency for now.
We rely on PSCI bindings anyways for the conduit and this should be
fine.
Link: https://lore.kernel.org/r/20200507144905.11397-1-sudeep.holla@arm.com
Fixes: 1dc6558062 ("firmware: arm_scmi: Add smc/hvc transport")
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
ASUS TF300T device may not work properly if firmware is asked to fully
re-initialize L2 cache after resume from LP2 suspend. The downstream
kernel of TF300T uses different opcode to enable cache after resuming
from LP2, this opcode also works fine on Nexus 7 and Ouya devices.
Supposedly, this may be needed by an older firmware versions.
Reported-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Tested-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Tested-by: Jasper Korten <jja2000@gmail.com>
Tested-by: David Heidelberg <david@ixit.cz>
Tested-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
To help the compiler figure out that efi_printk() will not modify
the string it is given, make the input argument type const char*.
While at it, simplify the implementation as well.
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
When building the x86 EFI stub with Clang, the libstub Makefile rules
that manipulate the ELF object files may throw an error like:
STUBCPY drivers/firmware/efi/libstub/efi-stub-helper.stub.o
strip: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10
objcopy: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10
This is the result of a LLVM feature [0] where symbol references are
stored in a LLVM specific .llvm_addrsig section in a non-transparent way,
causing generic ELF tools such as strip or objcopy to choke on them.
So force the compiler not to emit these sections, by passing the
appropriate command line option.
[0] https://sourceware.org/bugzilla/show_bug.cgi?id=23817
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Sami Tolvanen <samitolvanen@google.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Fangrui Song <maskray@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Commit
22090f84bc ("efi/libstub: unify EFI call wrappers for non-x86")
refactored the macros that are used to provide wrappers for mixed-mode
calls on x86, allowing us to boot a 64-bit kernel on 32-bit firmware.
Unfortunately, this broke mixed mode boot due to the fact that
efi_is_native() is not a macro on x86.
All of these macros should go together, so rather than testing each one
to see if it is defined, condition the generic macro definitions on a
new ARCH_HAS_EFISTUB_WRAPPERS, and remove the wrapper definitions on x86
as well if CONFIG_EFI_MIXED is not enabled.
Fixes: 22090f84bc ("efi/libstub: unify EFI call wrappers for non-x86")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200504150248.62482-1-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
As with most of the drivers, let us register this driver unconditionally
by dropping the checks for presence of firmware nodes(DT) or entries(ACPI).
Further, as mentioned in the commit acafce48b0 ("firmware: arm_sdei:
Fix DT platform device creation"), the core takes care of creation of
platform device when the appropriate device node is found and probe
is called accordingly.
Let us check only for the presence of ACPI firmware entry before creating
the platform device and flag warning if we fail.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Cc: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20200422122823.1390-1-sudeep.holla@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
When building arm64 allmodconfig:
ERROR: modpost: "zynqmp_pm_fpga_load" [drivers/fpga/zynqmp-fpga.ko] undefined!
ERROR: modpost: "zynqmp_pm_fpga_get_status" [drivers/fpga/zynqmp-fpga.ko] undefined!
These functions were added to drivers/fpga/zynqmp-fpga.c but not
exported so the module build breaks. Export them so that they can be
used in modules properly.
Fixes: 4db8180ffe ("firmware: xilinx: Remove eemi ops for fpga related APIs")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20200502025958.2714249-1-natechancellor@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
efi_parse_options can fail if it is unable to allocate space for a copy
of the command line. Check the return value to make sure it succeeded.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200430182843.2510180-12-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Factor out the initrd loading into a common function that can be called
both from the generic efi-stub.c and the x86-specific x86-stub.c.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200430182843.2510180-10-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Rename pr_efi to efi_info and pr_efi_err to efi_err to make it more
obvious that they are part of the EFI stub and not generic printk infra.
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200430182843.2510180-4-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
In several places 64-bit values need to be split up into two 32-bit
fields, in order to be backward-compatible with the old 32-bit ABIs.
Instead of open-coding this, add a helper function to set a 64-bit value
as two 32-bit fields.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200430182843.2510180-3-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
struct boot_params is only 4096 bytes, not 16384. Fix this by using
sizeof(struct boot_params) instead of hardcoding the incorrect value.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200430182843.2510180-2-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Currently, setup_graphics() ignores the return value of efi_setup_gop(). As
AllocatePool() does not zero out memory, the screen information table will
contain uninitialized data in this case.
We should free the screen information table if efi_setup_gop() returns an
error code.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Link: https://lore.kernel.org/r/20200426194946.112768-1-xypron.glpk@gmx.de
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Add sysfs interface to set boot health status from user space.
Add API used by this interface to communicate with firmware.
If PMUFW is compiled with CHECK_HEALTHY_BOOT, it will check the
healthy bit on FPD WDT expiration. If healthy bit is set by a user
application running in Linux, PMUFW will do APU only restart. If
healthy bit is not set during FPD WDT expiration, PMUFW will do
system restart.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Tejas Patel <tejas.patel@xilinx.com>
Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
Link: https://lore.kernel.org/r/1587761887-4279-26-git-send-email-jolly.shah@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Linux shutdown functionality implemented via PSCI system_off does
not include an option to set a scope, i.e. which parts of the system to
shut down.
This patch creates sysfs that allows to set the shutdown scope for the
next shutdown request. When the next shutdown is performed, the platform
specific portion of PSCI-system_off can use the chosen shutdown scope.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Stefan Krsmanovic <stefan.krsmanovic@aggios.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Tejas Patel <tejas.patel@xilinx.com>
Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
Link: https://lore.kernel.org/r/1587761887-4279-25-git-send-email-jolly.shah@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add system shutdown API interface which asks firmware to
perform system shutdown/restart.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
Link: https://lore.kernel.org/r/1587761887-4279-24-git-send-email-jolly.shah@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add firmware-ggs sysfs interface which provides read/write
interface to global storage registers.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Tejas Patel <tejas.patel@xilinx.com>
Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
Link: https://lore.kernel.org/r/1587761887-4279-23-git-send-email-jolly.shah@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use direct function call instead of using eemi ops for fpga related
APIs. Also remove eemi ops structure.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
Link: https://lore.kernel.org/r/1587761887-4279-21-git-send-email-jolly.shah@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use direct function call instead of using eemi ops for
clock_getdivider.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
Link: https://lore.kernel.org/r/1587761887-4279-9-git-send-email-jolly.shah@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use direct function call instead of using eemi ops for
clock_setdivider.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
Link: https://lore.kernel.org/r/1587761887-4279-8-git-send-email-jolly.shah@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use direct function calls instead of using eemi ops. So remove
eemi ops for get_api_version and use direct function call.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Jolly Shah <jolly.shah@xilinx.com>
Link: https://lore.kernel.org/r/1587761887-4279-2-git-send-email-jolly.shah@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Intel service layer driver has defined error codes for the
specific services, which started from FPGA configuration then RSU
(Remote Status Update).
Intel service layer driver should define the standard error codes
rather than keep adding more error codes for the new services.
The standard error codes will be used by all the clients of Intel service
layer driver.
Replace FPGA and RSU specific error codes with Intel service layer’s
Common error codes.
Signed-off-by: Richard Gong <richard.gong@intel.com>
Link: https://lore.kernel.org/r/1586897274-307-2-git-send-email-richard.gong@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are some small firmware/driver core/debugfs fixes for 5.7-rc3.
The debugfs change is now possible as now the last users of
debugfs_create_u32() have been fixed up in the different trees that got
merged into 5.7-rc1, and I don't want it creeping back in.
The firmware changes did cause a regression in linux-next, so the final
patch here reverts part of that, re-exporting the symbol to resolve that
issue. All of these patches, with the exception of the final one, have
been in linux-next with only that one reported issue.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXqVliw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymf6ACfS5HoPt+kWKtfKteN/mt6WUeJz6oAoMDg4Qvf
4ncqmH9jt0lj5NAwHxFi
=DP2q
-----END PGP SIGNATURE-----
Merge tag 'driver-core-5.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core fixes from Greg KH:
"Here are some small firmware/driver core/debugfs fixes for 5.7-rc3.
The debugfs change is now possible as now the last users of
debugfs_create_u32() have been fixed up in the different trees that
got merged into 5.7-rc1, and I don't want it creeping back in.
The firmware changes did cause a regression in linux-next, so the
final patch here reverts part of that, re-exporting the symbol to
resolve that issue. All of these patches, with the exception of the
final one, have been in linux-next with only that one reported issue"
* tag 'driver-core-5.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
firmware_loader: revert removal of the fw_fallback_config export
debugfs: remove return value of debugfs_create_u32()
firmware_loader: remove unused exports
firmware: imx: fix compile-testing
Commit:
cf6b836648 ("efi/libstub: Make initrd file loader configurable")
inadvertently disabled support on x86 for loading an initrd passed via
the initrd= option on the kernel command line.
Add X86 to the newly introduced Kconfig option's title and depends
declarations, so it gets enabled by default, as before.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: linux-efi@vger.kernel.org
Instead of making match_config_table() test its table_types pointer for
NULL-ness, omit the call entirely if no arch_tables pointer was provided
to efi_config_parse_tables().
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Increase legibility by adding whitespace to the efi_config_table_type_t
arrays that describe which EFI config tables we look for when going over
the firmware provided list. While at it, replace the 'name' char pointer
with a char array, which is more space efficient on relocatable 64-bit
kernels, as it avoids a 8 byte pointer and the associated relocation
data (24 bytes when using RELA format)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>