2090 Commits

Author SHA1 Message Date
Arvind Sankar
420b6d00ca efi/arm: Remove __efistub_global annotation
Instead of using __efistub_global to force variables into the .data
section, leave them in the .bss but pull the EFI stub's .bss section
into .data in the linker script for the compressed kernel.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20200416151227.3360778-2-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24 14:52:16 +02:00
Ard Biesheuvel
685d8164b5 efi/libstub: Move efi_relocate_kernel() into separate source file
Move efi_relocate_kernel() into a separate source file, so that it
only gets pulled into builds for architectures that use it. Since
efi_relocate_kernel() is the only user of efi_low_alloc(), let's
move that over as well.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24 14:52:16 +02:00
Ard Biesheuvel
e71356fe29 efi/libstub/arm64: Switch to ordinary page allocator for kernel image
It is no longer necessary to locate the kernel as low as possible in
physical memory, and so we can switch from efi_low_alloc() [which is
a rather nasty concoction on top of GetMemoryMap()] to a new helper
called efi_allocate_pages_aligned(), which simply rounds up the size
to account for the alignment, and frees the misaligned pages again.

So considering that the kernel can live anywhere in the physical
address space, as long as its alignment requirements are met, let's
switch to efi_allocate_pages_aligned() to allocate the pages.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24 14:52:16 +02:00
Ard Biesheuvel
43b1df0e01 efi/libstub: Add API function to allocate aligned memory
Break out the code to create an aligned page allocation from mem.c
and move it into a function efi_allocate_pages_aligned() in alignedmem.c.
Update efi_allocate_pages() to invoke it unless the minimum alignment
equals the EFI page size (4 KB), in which case the ordinary page
allocator is sufficient. This way, efi_allocate_pages_aligned() will
only be pulled into the build if it is actually being used (which will
be on arm64 only in the immediate future)

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24 14:52:16 +02:00
Ard Biesheuvel
5d12da9dd6 efi/libstub/arm64: Simplify randomized loading of kernel image
The KASLR code path in the arm64 version of the EFI stub incorporates
some overly complicated logic to randomly allocate a region of the right
alignment: there is no need to randomize the placement of the kernel
modulo 2 MiB separately from the placement of the 2 MiB aligned allocation
itself - we can simply follow the same logic used by the non-randomized
placement, which is to allocate at the correct alignment, and only take
TEXT_OFFSET into account if it is not a round multiple of the alignment.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Ard Biesheuvel
82046702e2 efi/libstub/arm64: Replace 'preferred' offset with alignment check
The notion of a 'preferred' load offset for the kernel dates back to the
times when the kernel's primary mapping overlapped with the linear region,
and memory below it could not be used at all.

Today, the arm64 kernel does not really care where it is loaded in physical
memory, as long as the alignment requirements are met, and so there is no
point in unconditionally moving the kernel to a new location in memory at
boot. Instead, we can
- check for a KASLR seed, and randomly reallocate the kernel if one is
  provided
- otherwise, check whether the alignment requirements are met for the
  current placement of the kernel, and just run it in place if they are
- finally, do an ordinary page allocation and reallocate the kernel to a
  suitably aligned buffer anywhere in memory.

By the same reasoning, there is no need to take TEXT_OFFSET into account
if it is a round multiple of the minimum alignment, which is the usual
case for relocatable kernels with TEXT_OFFSET randomization disabled.
Otherwise, it suffices to use the relative misaligment of TEXT_OFFSET
when reallocating the kernel.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Ard Biesheuvel
c37c9162a2 efi/libstub/random: Increase random alloc granularity
The implementation of efi_random_alloc() arbitrarily truncates the
provided random seed to 16 bits, which limits the granularity of the
randomly chosen allocation offset in memory. This is currently only
an issue if the size of physical memory exceeds 128 GB, but going
forward, we will reduce the allocation alignment to 64 KB, and this
means we need to increase the granularity to ensure that the random
memory allocations are distributed evenly.

We will need to switch to 64-bit arithmetic for the multiplication,
but this does not result in 64-bit integer intrinsic calls on ARM or
on i386.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Ard Biesheuvel
e1df73e2d1 efi/libstub/random: Align allocate size to EFI_ALLOC_ALIGN
The EFI stub uses a per-architecture #define for the minimum base
and size alignment of page allocations, which is set to 4 KB for
all architecures except arm64, which uses 64 KB, to ensure that
allocations can always be (un)mapped efficiently, regardless of
the page size used by the kernel proper, which could be a kexec'ee

The API wrappers around page based allocations assume that this
alignment is always taken into account, and so efi_free() will
also round up its size argument to EFI_ALLOC_ALIGN.

Currently, efi_random_alloc() does not honour this alignment for
the allocated size, and so freeing such an allocation may result
in unrelated memory to be freed, potentially leading to issues
after boot. So let's round up size in efi_random_alloc() as well.

Fixes: 2ddbfc81eac84a29 ("efi: stub: add implementation of efi_random_alloc()")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
45d97a749e efi/gop: Allow automatically choosing the best mode
Add the ability to automatically pick the highest resolution video mode
(defined as the product of vertical and horizontal resolution) by using
a command-line argument of the form
	video=efifb:auto

If there are multiple modes with the highest resolution, pick one with
the highest color depth.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200328160601.378299-2-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
9a1663bc4d efi/gop: Allow specifying depth as well as resolution
Extend the video mode argument to handle an optional color depth
specification of the form
	video=efifb:<xres>x<yres>[-(rgb|bgr|<bpp>)]

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-14-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
d9ff0323d0 efi/gop: Allow specifying mode by <xres>x<yres>
Add the ability to choose a video mode using a command-line argument of
the form
	video=efifb:<xres>x<yres>

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-13-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
fffb68047e efi/gop: Allow specifying mode number on command line
Add the ability to choose a video mode for the selected gop by using a
command-line argument of the form
	video=efifb:mode=<n>

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-12-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
b4b89a0272 efi/gop: Add prototypes for query_mode and set_mode
Add prototypes and argmap for the Graphics Output Protocol's QueryMode
and SetMode functions.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-11-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
d49fd4bbf9 efi/gop: Remove unreachable code from setup_pixel_info
pixel_format must be one of
	PIXEL_RGB_RESERVED_8BIT_PER_COLOR
	PIXEL_BGR_RESERVED_8BIT_PER_COLOR
	PIXEL_BIT_MASK
since we skip PIXEL_BLT_ONLY when finding a gop.

Remove the redundant code and add another check in find_gop to skip any
pixel formats that we don't know about, in case a later version of the
UEFI spec adds one.

Reformat the code a little.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-10-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
9867fc9de6 efi/gop: Use helper macros for find_bits
Use the __ffs/__fls macros to calculate the position and size of the
mask.

Correct type of mask to u32 instead of unsigned long.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-9-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
f1d1853bdb efi/gop: Use helper macros for populating lfb_base
Use the lower/upper_32_bits macros from kernel.h to initialize
si->lfb_base and si->ext_lfb_base.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-8-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
e484c594ba efi/gop: Move variable declarations into loop block
Declare the variables inside the block where they're used.

Get rid of a couple of redundant initializers.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-7-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
8e0a22e2b0 efi/gop: Slightly re-arrange logic of find_gop
Small cleanup to get rid of conout_found.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-6-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
ecf53091f3 efi/gop: Factor out locating the gop into a function
Move the loop to find a gop into its own function.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-5-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
6327e6d0e4 efi/gop: Get mode information outside the loop
Move extraction of the mode information parameters outside the loop to
find the gop, and eliminate some redundant variables.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-4-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
8cd207973c efi/gop: Move check for framebuffer before con_out
If the gop doesn't have a framebuffer, there's no point in checking for
con_out support.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-3-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Arvind Sankar
bd45870409 efi/gop: Remove redundant current_fb_base
current_fb_base isn't used for anything except assigning to fb_base if
we locate a suitable gop.

Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/20200320020028.1936003-2-nivedita@alum.mit.edu
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Zou Wei
87cd6378b3 efi/libstub/arm: Make install_memreserve_table static
Fix the following sparse warning:

drivers/firmware/efi/libstub/arm-stub.c:68:6: warning:
symbol 'install_memreserve_table' was not declared. Should it be static?

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1587643713-28169-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Ard Biesheuvel
22090f84bc efi/libstub: unify EFI call wrappers for non-x86
We have wrappers around EFI calls so that x86 can define special
versions for mixed mode, while all other architectures can use the
same simple definition that just issues the call directly.
In preparation for the arrival of yet another architecture that doesn't
need anything special here (RISC-V), let's move the default definition
into a shared header.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Ard Biesheuvel
cf6b836648 efi/libstub: Make initrd file loader configurable
Loading an initrd passed via the kernel command line is deprecated: it
is limited to files that reside in the same volume as the one the kernel
itself was loaded from, and we have more flexible ways to achieve the
same. So make it configurable so new architectures can decide not to
enable it.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 20:15:06 +02:00
Linus Torvalds
7adc4b3999 ARM: SoC fixes
A few smaller fixes for v5.7-rc3: The majority are fixes for bugs I found
 after restarting my randconfig build testing that had been dormant for
 a while.
 
 On the Nokia N950/N9 phone, a DT fix is required to address a boot
 regression.
 
 For the bcm283x (Raspberry Pi), two DT fixes address minor issues.
 
 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAl6hsLwACgkQmmx57+YA
 GNmL2hAAsbdQcEkAX/y/dSyCU3rg9qxwAGzpjshewEboLy6Sh4LWShraJ2o8snH6
 EAGVOb8O6giB09DLL9WOCEoVK6nHan98BBEDUvPLobdXkv+zrmva6QHKYHX1y2cs
 TpV/2klyOJn1HHtLzioONbc37FtFEdW4DVf/2WH12u9hGUOLat5ULIeXtakrj9xy
 iL/BuLcYW396ZGTTFa1XkLeCqzRvtkAqoMtZIjr2hXTi/IkgkIUZRatIRu54pKYo
 VNiwY9BnCJknl+QmPkavmm9qdZhmJU4cxFX+wnu7Sh45Xflw9J14J16wBe/BZWO+
 joOtpak+sF+kYPnS5Uv9Ie3dalo98w0CBYf40x2dznnqMyOJtPPbLhwjf3jzcLhk
 dUVHra14vaWMtPCHg/PDTBjtxu2SaLWcELqn3hek/Zwr09zUgelyTquTAoHkXzgF
 ApYtT8ym04y9uirFf1Cg59bBxmIoC85I4l487ly0SQtU7vE4piSM2KI+jnp3zn+3
 +7TC85UYhtqNu7asYLAN6PcOOg+p4jpRyW/SK3dSoJw1f839fKji77aeEnIAEWxN
 Qb4qJHYL+9Xy47mjJjH3TarRo7QulGiAgZV21uOrZecDiM8bMpDGtRXTqAW8yfsb
 awDLmGvBaYb+xN/cc3X73inhXct48OLvz5GKRYLtIOzQFxAu/cM=
 =K1jH
 -----END PGP SIGNATURE-----

Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

Pull ARM SoC fixes from Arnd Bergmann:
 "A few smaller fixes for v5.7-rc3: The majority are fixes for bugs I
  found after restarting my randconfig build testing that had been
  dormant for a while.

  On the Nokia N950/N9 phone, a DT fix is required to address a boot
  regression.

  For the bcm283x (Raspberry Pi), two DT fixes address minor issues"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  soc: imx8: select SOC_BUS
  soc: tegra: fix tegra_pmc_get_suspend_mode definition
  soc: fsl: dpio: avoid stack usage warning
  soc: fsl: dpio: fix incorrect pointer conversions
  ARM: imx: provide v7_cpu_resume() only on ARM_CPU_SUSPEND=y
  ARM: dts: bcm283x: Disable dsi0 node
  firmware: xilinx: make firmware_debugfs_root static
  drivers: soc: xilinx: fix firmware driver Kconfig dependency
  ARM: dts: bcm283x: Add cells encoding format to firmware bus
  ARM: dts: OMAP3: disable RNG on N950/N9
2020-04-23 09:36:40 -07:00
Franck LENORMAND
f5f27b79ea firmware: imx: scu: Fix corruption of header
The header of the message to send can be changed if the
response is longer than the request:
 - 1st word, the header is sent
 - the remaining words of the message are sent
 - the response is received asynchronously during the
   execution of the loop, changing the size field in
   the header
 - the for loop test the termination condition using
   the corrupted header

It is the case for the API build_info which has just a
header as request but 3 words in response.

This issue is fixed storing the header locally instead of
using a pointer on it.

Fixes: edbee095fafb (firmware: imx: add SCU firmware driver support)

Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Cc: stable@vger.kernel.org
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-23 22:35:02 +08:00
Atish Patra
2e0eb483c0 efi/libstub: Move arm-stub to a common file
Most of the arm-stub code is written in an architecture independent manner.
As a result, RISC-V can reuse most of the arm-stub code.

Rename the arm-stub.c to efi-stub.c so that ARM, ARM64 and RISC-V can use it.
This patch doesn't introduce any functional changes.

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Link: https://lore.kernel.org/r/20200415195422.19866-2-atish.patra@wdc.com
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23 14:16:28 +02:00
Thierry Reding
d70f5e541a firmware: tegra: Make BPMP a regular driver
The Tegra BPMP driver typically ends up deferring probe because it wants
to attach to the SMMU, so there's little sense in registering it at the
core init-level.

One side-effect of this is that the driver will be probed later even if
it doesn't want to attach to an SMMU, which means that consumers will
end up deferring probe, which in turn takes care of ordering the suspend
and resume queue in the correct way. Currently since suspend/resume
order depends on instantiation order, and because BPMP is listed at the
very end of the device tree (after most of its consumers), the suspend
and resume queue is ordered wrongly, which can cause issues for drivers
(like I2C) which suspend after and resume before BPMP. In the case of
I2C this typically leads to the clock failing to enable.

Besides fixing this suspend/resume ordering issue, this also has the
added benefit of allowing the driver to be built as a loadable module,
which can help decrease the size of multiplatform kernel.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-04-22 00:02:10 +02:00
Christoph Hellwig
459b1f86f1 firmware: qcom_scm: fix bogous abuse of dma-direct internals
As far as the device is concerned the dma address is the physical
address.  There is no need to convert it to a physical address,
especially not using dma-direct internals that are not available
to drivers and which will interact badly with IOMMUs.  Last but not
least the commit introducing it claimed to just fix a type issue,
but actually changed behavior.

Fixes: 6e37ccf78a532 ("firmware: qcom_scm: Use proper types for dma mappings")
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20200414123136.441454-1-hch@lst.de
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-20 23:20:00 -07:00
Jason Yan
820f63652b firmware: qcom_scm: Remove unneeded conversion to bool
The '>' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:

drivers/firmware/qcom_scm.c:946:25-30: WARNING: conversion to bool not
needed here

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200420123516.7888-1-yanaijie@huawei.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-04-20 12:51:55 -07:00
Sudeep Holla
f7199cf489 firmware: arm_scmi: Fix return error code in smc_send_message
SMCCC can return NOT_SUPPORTED(-1). Map it to appropriate Linux error
codes namely -EOPNOTSUPP.

Link: https://lore.kernel.org/r/20200417103232.6896-1-sudeep.holla@arm.com
Reported-and-Tested-by:: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-20 17:57:34 +01:00
Cristian Marussi
c5bceb98ce firmware: arm_scmi: Fix handling of unexpected delayed responses
Upon reception of an unexpected bogus delayed response, clear the channel
and bail-out safely.

Link: https://lore.kernel.org/r/20200420152315.21008-5-cristian.marussi@arm.com
Fixes: 4d09852b6f01 ("firmware: arm_scmi: Add support for notifications message processing")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-20 17:25:26 +01:00
Cristian Marussi
d04fb2b2dd firmware: arm_scmi: Clear channel for delayed responses
Clear channel properly when done processing a delayed response.
This will let the platform firmware know that the channel is now free to
use it for any new delayed response or notification.

Link: https://lore.kernel.org/r/20200420152315.21008-4-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
(sudeep.holla: Updated commit log to reflect that channel is now free for
 platform to use)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-20 17:25:26 +01:00
Cristian Marussi
b37f5cc8d2 firmware: arm_scmi: Clear channel on reception of unexpected responses
When an unexpected response message is received we currently warn the user
and bail-out, ensure to also free the channel by invoking the transport
independent operation .clear_channel()

Link: https://lore.kernel.org/r/20200420152315.21008-3-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-20 17:25:26 +01:00
Cristian Marussi
87dff4e63c firmware: arm_scmi: Rename .clear_notification() transport_ops
SCMI transport operation .clear_notification() is indeed a generic method
to clear the channel in a transport dependent way, as such it could be a
useful helper also in other contexts.

Rename such method as .clear_channel(), renaming accordingly also its
already existent call-sites.

No functional change.

Link: https://lore.kernel.org/r/20200420152315.21008-2-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-20 17:25:26 +01:00
Peng Fan
f25a066d1a firmware: imx-scu: Support one TX and one RX
Current imx-scu requires four TX and four RX to communicate with
SCU. This is low efficient and causes lots of mailbox interrupts.

With imx-mailbox driver could support one TX to use all four transmit
registers and one RX to use all four receive registers, imx-scu
could use one TX and one RX.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-20 22:46:14 +08:00
Arnd Bergmann
32ec783ae1 firmware: imx: fix compile-testing
It is nice to allow compile-testing the firmware drivers, but this
fails when the dependency is a loadable module:

aarch64-linux-ld: drivers/firmware/imx/scu-pd.o: in function `imx_sc_pd_power':
scu-pd.c:(.text+0xd8): undefined reference to `imx_scu_call_rpc'
aarch64-linux-ld: scu-pd.c:(.text+0x108): undefined reference to `imx_scu_call_rpc'
aarch64-linux-ld: drivers/firmware/imx/scu-pd.o: in function `imx_sc_pd_probe':

Change the dependencies to ensure that any driver we depend on is
either reachable or we are compile-testing and it is disabled,
effectively reverting most of the previous changes that turned
out to be incorrect.

Fixes: a9f85f93ed73 ("firmware: imx: add COMPILE_TEST support")
Fixes: 5b00b8375416 ("firmware: imx: add COMPILE_TEST for IMX_SCU driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200408190314.695067-1-arnd@arndb.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-17 09:57:44 +02:00
Jason Yan
f5ba30ba48 firmware: xilinx: make firmware_debugfs_root static
Fix the following sparse warning:

drivers/firmware/xilinx/zynqmp-debug.c:38:15: warning: symbol
'firmware_debugfs_root' was not declared. Should it be static?

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200415084311.24857-1-yanaijie@huawei.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2020-04-15 10:25:20 +02:00
Sudeep Holla
4d09852b6f firmware: arm_scmi: Add support for notifications message processing
Add the mechanisms to distinguish notifications from delayed responses
and command responses. Also add support to properly fetch notification
messages upon reception. Notifications processing does not continue any
further after the fetch phase.

Link: https://lore.kernel.org/r/20200327143438.5382-5-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
[Reworked/renamed scmi_handle_xfer_delayed_resp()]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:49 +01:00
Cristian Marussi
d5141f37c4 firmware: arm_scmi: Add notifications support in transport layer
Add common transport-layer methods to:
 - fetch a notification instead of a response
 - clear a pending notification

Add also all the needed support in mailbox/shmem transports.

Link: https://lore.kernel.org/r/20200327143438.5382-4-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:49 +01:00
Sudeep Holla
2264417a9a firmware: arm_scmi: Update protocol commands and notification list
Add commands' enumerations and messages definitions for all existing
notify-enable commands across all protocols.

Link: https://lore.kernel.org/r/20200327143438.5382-3-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:49 +01:00
Sudeep Holla
4ebd8f6dea firmware: arm_scmi: Add receive buffer support for notifications
With all the plumbing in place, let's just add the separate dedicated
receive buffers to handle notifications that can arrive asynchronously
from the platform firmware to OS.

Also add one check to see if the platform supports any receive channels
before allocating the receive buffers: since those buffers are optionally
supported though, the whole xfer initialization is also postponed to be
able to check for their existence in advance.

Link: https://lore.kernel.org/r/20200327143438.5382-2-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
[Changed parameters in __scmi_xfer_info_init()]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:49 +01:00
Sudeep Holla
4e44590ee4 firmware: arm_scmi: Drop checking for shmem property in parent node
The scmi protocol core driver checks for the channel availability
before evaluating the shmem property. If the individual protocols
don't have separate channel assigned to them, the channel alloted
for the BASE protocol is reused automatically.

Therefore there is no need to check for the shmem property in the
parent node if it is absent in the child protocol node.

Link: https://lore.kernel.org/r/20200327163654.13389-5-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:49 +01:00
Sudeep Holla
8aa6e12bbf firmware: arm_scmi: Check shmem property for channel availablity
Instead of declaring the channel availabilty unconditionally, let us
check for the presence of "shmem" property and return the channel
availablity accordingly.

Link: https://lore.kernel.org/r/20200327163654.13389-4-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:48 +01:00
Sudeep Holla
b9d15ee21c firmware: arm_scmi: Drop empty stub for smc_mark_txdone
The scmi protocol core driver check for non NULL mark_txdone before
invoking the same. There is no need to provide a empty stub. SMC/HVC
calls are synchronous and the call return indicates the completion.

Link: https://lore.kernel.org/r/20200327163654.13389-3-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:48 +01:00
Sudeep Holla
18988265b8 firmware: arm_scmi: Make mutex channel specific
In order to support multiple SMC/HVC transport channels with associated
shared memory, it is better to maintain the mutex per channel instead of
existing global one.

Move the smc_mutex into the scmi_smc structure and also rename it to
shmem_lock which is more appropriate for it's use.

Link: https://lore.kernel.org/r/20200327163654.13389-2-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:48 +01:00
Peng Fan
1dc6558062 firmware: arm_scmi: Add smc/hvc transport
Use the value of "arm,smc-id" property from the device tree as the first
argument for SMCCC call leaving all the other arguments as zero for now.

There is no Rx, only Tx because of smc/hvc not support Rx.

Link: https://lore.kernel.org/r/1583673879-20714-3-git-send-email-peng.fan@nxp.com
Signed-off-by: Peng Fan <peng.fan@nxp.com>
[sudeep.holla: reworded commit log/subject and fixed !HAVE_ARM_SMCCC build]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:48 +01:00
Ard Biesheuvel
464fb126d9 efi/libstub/file: Merge file name buffers to reduce stack usage
Arnd reports that commit

  9302c1bb8e47 ("efi/libstub: Rewrite file I/O routine")

reworks the file I/O routines in a way that triggers the following
warning:

  drivers/firmware/efi/libstub/file.c:240:1: warning: the frame size
            of 1200 bytes is larger than 1024 bytes [-Wframe-larger-than=]

We can work around this issue dropping an instance of efi_char16_t[256]
from the stack frame, and reusing the 'filename' field of the file info
struct that we use to obtain file information from EFI (which contains
the file name even though we already know it since we used it to open
the file in the first place)

Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200409130434.6736-8-ardb@kernel.org
2020-04-14 08:32:15 +02:00
Arvind Sankar
21cb9b4143 efi/x86: Always relocate the kernel for EFI handover entry
Commit

  d5cdf4cfeac9 ("efi/x86: Don't relocate the kernel unless necessary")

tries to avoid relocating the kernel in the EFI stub as far as possible.

However, when systemd-boot is used to boot a unified kernel image [1],
the image is constructed by embedding the bzImage as a .linux section in
a PE executable that contains a small stub loader from systemd that will
call the EFI stub handover entry, together with additional sections and
potentially an initrd. When this image is constructed, by for example
dracut, the initrd is placed after the bzImage without ensuring that at
least init_size bytes are available for the bzImage. If the kernel is
not relocated by the EFI stub, this could result in the compressed
kernel's startup code in head_{32,64}.S overwriting the initrd.

To prevent this, unconditionally relocate the kernel if the EFI stub was
entered via the handover entry point.

[1] https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images

Fixes: d5cdf4cfeac9 ("efi/x86: Don't relocate the kernel unless necessary")
Reported-by: Sergey Shatunov <me@prok.pw>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200406180614.429454-2-nivedita@alum.mit.edu
Link: https://lore.kernel.org/r/20200409130434.6736-5-ardb@kernel.org
2020-04-14 08:32:13 +02:00