Split off the file I/O support code into a separate source file so
it ends up in a separate object file in the static library, allowing
the linker to omit it if the routines are not used.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

get_dram_base() is only called from arm-stub.c so move it into
the same source file as its caller.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

efi_random_alloc() is only used on arm64, but as it shares a source
file with efi_random_get_seed(), the latter will pull in the former
on other architectures as well.

Let's take advantage of the fact that libstub is a static library,
and so the linker will only incorporate objects that are needed to
satisfy dependencies in other objects. This means we can move the
random alloc code to a separate source file that gets built
unconditionally, but only used when needed.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

We now support cmdline data that is located in memory that is not
32-bit addressable, so relax the allocation limit on systems where
this feature is enabled.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Move all the declarations that are only used in stub code from
linux/efi.h to efistub.h which is only included locally.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

We now support bootparams structures that are located in memory that
is not 32-bit addressable, so relax the allocation limit on systems
where this feature is enabled.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Align the naming of efi_file_io_interface_t and efi_file_handle_t with
the UEFI spec, and call them efi_simple_file_system_protocol_t and
efi_file_protocol_t, respectively, using the same convention we use
for all other type definitions that originate in the UEFI spec.

While at it, move the definitions to efistub.h, so they are only seen
by code that needs them.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Most of the EFI stub source files of all architectures reside under
drivers/firmware/efi/libstub, where they share a Makefile with special
CFLAGS and an include file with declarations that are only relevant
for stub code.

Currently, we carry a lot of stub specific stuff in linux/efi.h only
because eboot.c in arch/x86 needs them as well. So let's move eboot.c
into libstub/, and move the contents of eboot.h that we still care
about into efistub.h
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

The implementation of efi_high_alloc() uses a complicated way of
traversing the memory map to find an available region that is located
as close as possible to the provided upper limit, and calls AllocatePages
subsequently to create the allocation at that exact address.

This is precisely what the EFI_ALLOCATE_MAX_ADDRESS allocation type
argument to AllocatePages() does, and considering that EFI_ALLOC_ALIGN
only exceeds EFI_PAGE_SIZE on arm64, let's use AllocatePages() directly
and implement the alignment using code that the compiler can remove if
it does not exceed EFI_PAGE_SIZE.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Create a new source file mem.c to keep the routines involved in memory
allocation and deallocation and manipulation of the EFI memory map.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

The arm64 kernel no longer requires the FDT blob to fit inside a
naturally aligned 2 MB memory block, so remove the code that aligns
the allocation to 2 MB.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Instead of setting the visibility pragma for a small set of symbol
declarations that could result in absolute references that we cannot
support in the stub, declare hidden visibility for all code in the
EFI stub, which is more robust and future proof.

To ensure that the #pragma is taken into account before any other
includes are processed, put it in a header file of its own and
include it via the compiler command line using the -include option.
Signed-off-by: NArd Biesheuvel <ardb@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
inadvertenly introduced[3] to the codebase from now on.

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 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200211231421.GA15697@embeddedorSigned-off-by: NArd Biesheuvel <ardb@kernel.org>

The UEFI spec defines (and deprecates) a misguided and shortlived
memory protection feature that is based on splitting memory regions
covering PE/COFF executables into separate code and data regions,
without annotating them as belonging to the same executable image.
When the OS assigns the virtual addresses of these regions, it may
move them around arbitrarily, without taking into account that the
PE/COFF code sections may contain relative references into the data
sections, which means the relative placement of these segments has
to be preserved or the executable image will be corrupted.

The original workaround on arm64 was to ensure that adjacent regions
of the same type were mapped adjacently in the virtual mapping, but
this requires sorting of the memory map, which we would prefer to
avoid.

Considering that the native physical mapping of the PE/COFF images
does not suffer from this issue, let's preserve it at runtime, and
install it as the virtual mapping as well.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Some (somewhat older) laptops have a correct BGRT table, except that the
version field is 0 instead of 1.

This has been seen on several Ivy Bridge based Lenovo models.

For now the spec. only defines version 1, so it is reasonably safe to
assume that tables with a version of 0 really are version 1 too,
which is what this commit does so that the BGRT table will be accepted
by the kernel on laptop models with this issue.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200131130623.33875-1-hdegoede@redhat.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>

Expose efi_entry() as the PE/COFF entrypoint directly, instead of
jumping into a wrapper that fiddles with stack buffers and other
stuff that the compiler is much better at. The only reason this
code exists is to obtain a pointer to the base of the image, but
we can get the same value from the loaded_image protocol, which
we already need for other reasons anyway.

Update the return type as well, to make it consistent with what
is required for a PE/COFF executable entrypoint.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Now walk_page_range() can walk kernel page tables, we can switch the arm64
ptdump code over to using it, simplifying the code.

Link: http://lkml.kernel.org/r/20191218162402.45610-22-steven.price@arm.comSigned-off-by: NSteven Price <steven.price@arm.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Burton <paul.burton@mips.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Will Deacon <will@kernel.org>
Cc: Zong Li <zong.li@sifive.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Warn user if clock is used by more than allowed devices.
This check is done by firmware and returns respective
error code. Upon receiving error code for excessive user,
warn user for the same.

This change is done to restrict VPLL use count. It is
assumed that VPLL is used by one user only.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NRajan Vaja <rajan.vaja@xilinx.com>
Link: https://lkml.kernel.org/r/1575527759-26452-4-git-send-email-rajan.vaja@xilinx.comAcked-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NStephen Boyd <sboyd@kernel.org>

Dave noticed that when specifying multiple efi_fake_mem= entries only
the last entry was successfully being reflected in the efi memory map.
This is due to the fact that the efi_memmap_insert() is being called
multiple times, but on successive invocations the insertion should be
applied to the last new memmap rather than the original map at
efi_fake_memmap() entry.

Rework efi_fake_memmap() to install the new memory map after each
efi_fake_mem= entry is parsed.

This also fixes an issue in efi_fake_memmap() that caused it to litter
emtpy entries into the end of the efi memory map. An empty entry causes
efi_memmap_insert() to attempt more memmap splits / copies than
efi_memmap_split_count() accounted for when sizing the new map. When
that happens efi_memmap_insert() may overrun its allocation, and if you
are lucky will spill over to an unmapped page leading to crash
signature like the following rather than silent corruption:

    BUG: unable to handle page fault for address: ffffffffff281000
    [..]
    RIP: 0010:efi_memmap_insert+0x11d/0x191
    [..]
    Call Trace:
     ? bgrt_init+0xbe/0xbe
     ? efi_arch_mem_reserve+0x1cb/0x228
     ? acpi_parse_bgrt+0xa/0xd
     ? acpi_table_parse+0x86/0xb8
     ? acpi_boot_init+0x494/0x4e3
     ? acpi_parse_x2apic+0x87/0x87
     ? setup_acpi_sci+0xa2/0xa2
     ? setup_arch+0x8db/0x9e1
     ? start_kernel+0x6a/0x547
     ? secondary_startup_64+0xb6/0xc0

Commit af164898 "x86/efi: Update e820 with reserved EFI boot
services data to fix kexec breakage" introduced more occurrences where
efi_memmap_insert() is invoked after an efi_fake_mem= configuration has
been parsed. Previously the side effects of vestigial empty entries were
benign, but with commit af164898 that follow-on efi_memmap_insert()
invocation triggers efi_memmap_insert() overruns.
Reported-by: NDave Young <dyoung@redhat.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20191231014630.GA24942@dhcp-128-65.nay.redhat.com
Link: https://lore.kernel.org/r/20200113172245.27925-14-ardb@kernel.org

With efi_fake_memmap() and efi_arch_mem_reserve() the efi table may be
updated and replaced multiple times. When that happens a previous
dynamically allocated efi memory map can be garbage collected. Use the
new EFI_MEMMAP_{SLAB,MEMBLOCK} flags to detect when a dynamically
allocated memory map is being replaced.

Debug statements in efi_memmap_free() reveal:

  efi: __efi_memmap_free:37: phys: 0x23ffdd580 size: 2688 flags: 0x2
  efi: __efi_memmap_free:37: phys: 0x9db00 size: 2640 flags: 0x2
  efi: __efi_memmap_free:37: phys: 0x9e580 size: 2640 flags: 0x2

...a savings of 7968 bytes on a qemu boot with 2 entries specified to
efi_fake_mem=.

[ ardb: added a comment to clarify that efi_memmap_free() does nothing when
        called from efi_clean_memmap(), i.e., with data->flags == 0x0 ]
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-13-ardb@kernel.org

In preparation for fixing efi_memmap_alloc() leaks, add support for
recording whether the memmap was dynamically allocated from slab,
memblock, or is the original physical memmap provided by the platform.

Given this tracking is established in efi_memmap_alloc() and needs to be
carried to efi_memmap_install(), use 'struct efi_memory_map_data' to
convey the flags.

Some small cleanups result from this reorganization, specifically the
removal of local variables for 'phys' and 'size' that are already
tracked in @data.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-12-ardb@kernel.org

In preparation for garbage collecting dynamically allocated EFI memory
maps, where the allocation method of memblock vs slab needs to be
recalled, convert the existing 'late' flag into a 'flags' bitmask.

Arrange for the flag to be passed via 'struct efi_memory_map_data'. This
structure grows additional flags in follow-on changes.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-11-ardb@kernel.org

A previous commit f99afd08 ("efi: Update efi_mem_type() to return an
error rather than 0") changed the return value from EFI_RESERVED_TYPE to
-EINVAL when the searched physical address is not present in any memory
descriptor. But the comment preceding the function never changed. Let's
change the comment now to reflect the new return value -EINVAL.
Signed-off-by: NAnshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-10-ardb@kernel.org

The new of_devlink support breaks PCIe probing on ARM platforms booting
via UEFI if the firmware exposes a EFI framebuffer that is backed by a
PCI device. The reason is that the probing order gets reversed,
resulting in a resource conflict on the framebuffer memory window when
the PCIe probes last, causing it to give up entirely.

Given that we rely on PCI quirks to deal with EFI framebuffers that get
moved around in memory, we cannot simply drop the memory reservation, so
instead, let's use the device link infrastructure to register this
dependency, and force the probing to occur in the expected order.
Co-developed-by: NSaravana Kannan <saravanak@google.com>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-9-ardb@kernel.org

Fixes coccicheck warning:

drivers/firmware/stratix10-svc.c:271:2-3: Unneeded semicolon
drivers/firmware/stratix10-svc.c:515:2-3: Unneeded semicolon
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: Nzhengbin <zhengbin13@huawei.com>
Link: https://lore.kernel.org/r/1576465378-11109-1-git-send-email-zhengbin13@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently this driver is loaded if the DMI string matches coreboot
and has a proper smi_command in the ACPI FADT table, but a GSMI handler in
SMM is an optional feature in coreboot.

So probe for a SMM GSMI handler before initializing the driver.
If the smihandler leaves the calling argument in %eax in the SMM save state
untouched that generally means the is no handler for GSMI.
Signed-off-by: NArthur Heymans <arthur@aheymans.xyz>
Signed-off-by: NPatrick Rudolph <patrick.rudolph@9elements.com>
Link: https://lore.kernel.org/r/20191118101934.22526-4-patrick.rudolph@9elements.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix a bug where the kernel module couldn't be loaded after unloading,
as the platform driver wasn't released on exit.
Signed-off-by: NArthur Heymans <arthur@aheymans.xyz>
Signed-off-by: NPatrick Rudolph <patrick.rudolph@9elements.com>
Link: https://lore.kernel.org/r/20191118101934.22526-3-patrick.rudolph@9elements.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix a bug where the kernel module can't be loaded after it has been
unloaded as the devices are still present and conflicting with the
to be created coreboot devices.
Signed-off-by: NPatrick Rudolph <patrick.rudolph@9elements.com>
Link: https://lore.kernel.org/r/20191118101934.22526-2-patrick.rudolph@9elements.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

According to iSCSI Boot Firmware Table Version 1.03 [1], the length of
the control table is ">= 18", where the optional expansion structure
pointer follow the mandatory ones. This allows for more than two NICs
and Targets.

[1] ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_firmware_table_v1.03.pdf

Let's enforce the minimum length of the control structure instead
instead of limiting it to the smallest allowed size.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad@darnok.org>

Add an option to disable the busmaster bit in the control register on
all PCI bridges before calling ExitBootServices() and passing control
to the runtime kernel. System firmware may configure the IOMMU to prevent
malicious PCI devices from being able to attack the OS via DMA. However,
since firmware can't guarantee that the OS is IOMMU-aware, it will tear
down IOMMU configuration when ExitBootServices() is called. This leaves
a window between where a hostile device could still cause damage before
Linux configures the IOMMU again.

If CONFIG_EFI_DISABLE_PCI_DMA is enabled or "efi=disable_early_pci_dma"
is passed on the command line, the EFI stub will clear the busmaster bit
on all PCI bridges before ExitBootServices() is called. This will
prevent any malicious PCI devices from being able to perform DMA until
the kernel reenables busmastering after configuring the IOMMU.

This option may cause failures with some poorly behaved hardware and
should not be enabled without testing. The kernel commandline options
"efi=disable_early_pci_dma" or "efi=no_disable_early_pci_dma" may be
used to override the default. Note that PCI devices downstream from PCI
bridges are disconnected from their drivers first, using the UEFI
driver model API, so that DMA can be disabled safely at the bridge
level.

[ardb: disconnect PCI I/O handles first, as suggested by Arvind]
Co-developed-by: NMatthew Garrett <mjg59@google.com>
Signed-off-by: NMatthew Garrett <mjg59@google.com>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Matthew Garrett <matthewgarrett@google.com>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20200103113953.9571-18-ardb@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

Introduce the ability to define macros to perform argument translation
for the calls that need it, and define them for the boot services that
we currently use.

When calling 32-bit firmware methods in mixed mode, all output
parameters that are 32-bit according to the firmware, but 64-bit in the
kernel (ie OUT UINTN * or OUT VOID **) must be initialized in the
kernel, or the upper 32 bits may contain garbage. Define macros that
zero out the upper 32 bits of the output before invoking the firmware
method.

When a 32-bit EFI call takes 64-bit arguments, the mixed-mode call must
push the two 32-bit halves as separate arguments onto the stack. This
can be achieved by splitting the argument into its two halves when
calling the assembler thunk. Define a macro to do this for the
free_pages boot service.
Signed-off-by: NArvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Matthew Garrett <mjg59@google.com>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20200103113953.9571-17-ardb@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

IMX DSP is only needed by SOF or any other module that
wants to communicate with the DSP. When SOF is build
as a module IMX DSP is forced to be built inside the
kernel image. This is not optimal, so allow IMX DSP
to be built as a module.
Signed-off-by: NDaniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

This patch deletes a stray tab.

Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: Colin King <colin.king@canonical.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMarek Behún <marek.behun@nic.cz>
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>

Dynamically support SMCCCC and legacy conventions by detecting which
convention to use at runtime. qcom_scm_call_atomic and qcom_scm_call can
then be moved in qcom_scm.c and use underlying convention backend as
appropriate. Thus, rename qcom_scm-64,-32 to reflect that they are
backends for -smc and -legacy, respectively.

Also add support for making SCM calls earlier than when SCM driver
probes to support use cases such as qcom_scm_set_cold_boot_addr. Support
is added by lazily initializing the convention and guarding the query
with a spin lock.  The limitation of these early SCM calls is that they
cannot use DMA, as in the case of >4 arguments for SMC convention and
any non-atomic call for legacy convention.

Tested-by: Brian Masney <masneyb@onstation.org> # arm32
Tested-by: NStephan Gerhold <stephan@gerhold.net>
Signed-off-by: NElliot Berman <eberman@codeaurora.org>
Link: https://lore.kernel.org/r/1578431066-19600-18-git-send-email-eberman@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

qcom_scm-32 and qcom_scm-64 implementations are nearly identical, so
make qcom_scm_call and qcom_scm_call_atomic unique to each and the SCM
descriptor creation common to each. There are the following catches:
- __qcom_scm_is_call_available is still in each -32,-64 implementation
  as the argument is unique to each convention
- For some functions, only one implementation was provided in -32 or
  -64. The actual implementation was moved into qcom_scm.c
- io_writel and io_readl in -64 were non-atomic calls and in -32 they
  were. Atomic is the better option, so use it.

Tested-by: Brian Masney <masneyb@onstation.org> # arm32
Tested-by: NStephan Gerhold <stephan@gerhold.net>
Signed-off-by: NElliot Berman <eberman@codeaurora.org>
Link: https://lore.kernel.org/r/1578431066-19600-17-git-send-email-eberman@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Definitions throughout qcom_scm are loosely grouped and loosely ordered.
Sort all the functions/definitions by service ID/command ID to improve
sanity when needing to add new functionality to this driver.
Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Brian Masney <masneyb@onstation.org> # arm32
Tested-by: NStephan Gerhold <stephan@gerhold.net>
Signed-off-by: NElliot Berman <eberman@codeaurora.org>
Link: https://lore.kernel.org/r/1578431066-19600-16-git-send-email-eberman@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Add unused "device" parameter to reduce merge friction between SMCCC and
legacy based conventions in an upcoming patch.

Tested-by: Brian Masney <masneyb@onstation.org> # arm32
Tested-by: NStephan Gerhold <stephan@gerhold.net>
Signed-off-by: NElliot Berman <eberman@codeaurora.org>
Link: https://lore.kernel.org/r/1578431066-19600-15-git-send-email-eberman@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Per [1], legacy calling convention supports up to 5 arguments and 3
return values. Create one function to support this combination, and
remove the original "atomic1" and "atomic2" variants for 1 and 2
arguments. This more closely aligns scm_legacy implementation with
scm_smc implementation.

[1]: https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/soc/qcom/scm.c?h=kernel.lnx.4.9.r28-rel#n1024

Tested-by: Brian Masney <masneyb@onstation.org> # arm32
Tested-by: NStephan Gerhold <stephan@gerhold.net>
Signed-off-by: NElliot Berman <eberman@codeaurora.org>
Link: https://lore.kernel.org/r/1578431066-19600-14-git-send-email-eberman@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Move SMCCC register filling to qcom_scm_call so that __scm_legacy_do
only needs to concern itself with retry mechanism. qcom_scm_call then is
responsible for translating qcom_scm_desc into the complete set of
register arguments and passing onto qcom_scm_call_do.

Tested-by: Brian Masney <masneyb@onstation.org> # arm32
Tested-by: NStephan Gerhold <stephan@gerhold.net>
Signed-off-by: NElliot Berman <eberman@codeaurora.org>
Link: https://lore.kernel.org/r/1578431066-19600-13-git-send-email-eberman@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Use qcom_scm_desc in non-atomic calls to remove legacy convention
details from every SCM wrapper function. Implementations were copied
from qcom_scm-64 and are functionally equivalent when using the
qcom_scm_desc and qcom_scm_res structs.

Tested-by: Brian Masney <masneyb@onstation.org> # arm32
Tested-by: NStephan Gerhold <stephan@gerhold.net>
Signed-off-by: NElliot Berman <eberman@codeaurora.org>
Link: https://lore.kernel.org/r/1578431066-19600-12-git-send-email-eberman@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>