linux-stable.git/drivers/firmware, branch v5.4.16

firmware: arm_scmi: Fix doorbell ring logic for !CONFIG_64BIT

2020-01-26T09:01:07+00:00

[ Upstream commit 7bd39bc6bfdf96f5df0f92199bbc1a3ee2f2adb8 ]

The logic to ring the scmi performance fastchannel ignores the
value read from the doorbell register in case of !CONFIG_64BIT.
This bug also shows up as warning with '-Wunused-but-set-variable' gcc
flag:

drivers/firmware/arm_scmi/perf.c: In function scmi_perf_fc_ring_db:
drivers/firmware/arm_scmi/perf.c:323:7: warning: variable val set but
			not used [-Wunused-but-set-variable]

Fix the same by aligning the logic with CONFIG_64BIT as used in the
macro SCMI_PERF_FC_RING_DB().

Fixes: 823839571d76 ("firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol")
Reported-by: Hulk Robot 
Reported-by: Zheng Yongjun 
Signed-off-by: Sudeep Holla 
Signed-off-by: Sasha Levin

firmware: imx: Remove call to devm_of_platform_populate

2020-01-26T09:01:05+00:00

[ Upstream commit 0e4e8cc30a2940c57448af1376e40d3c0996fb29 ]

IMX DSP device is created by SOF layer. The current call to
devm_of_platform_populate is not needed and it doesn't produce
any effects.

Fixes: ffbf23d50353915d ("firmware: imx: Add DSP IPC protocol interface)
Signed-off-by: Daniel Baluta 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

efi/earlycon: Fix write-combine mapping on x86

2020-01-23T07:22:38+00:00

commit d92b54570d24d017d2630e314b525ed792f5aa6c upstream.

On x86, until PAT is initialized, WC translates into UC-. Since we
calculate and store pgprot_writecombine(PAGE_KERNEL) when earlycon is
initialized, this means we actually use UC- mappings instead of WC
mappings, which makes scrolling very slow.

Instead store a boolean flag to indicate whether we want to use
writeback or write-combine mappings, and recalculate the actual pgprot_t
we need on every mapping. Once PAT is initialized, we will start using
write-combine mappings, which speeds up the scrolling considerably.

Signed-off-by: Arvind Sankar 
Signed-off-by: Ard Biesheuvel 
Cc: Hans de Goede 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation")
Link: https://lkml.kernel.org/r/20191224132909.102540-2-ardb@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

efi/earlycon: Remap entire framebuffer after page initialization

2020-01-12T11:21:16+00:00

[ Upstream commit b418d660bb9798d2249ac6a46c844389ef50b6a5 ]

When commit:

  69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation")

moved the x86 specific EFI earlyprintk implementation to a shared location,
it also tweaked the behaviour. In particular, it dropped a trick with full
framebuffer remapping after page initialization, leading to two regressions:

  1) very slow scrolling after page initialization,
  2) kernel hang when the 'keep_bootcon' command line argument is passed.

Putting the tweak back fixes #2 and mitigates #1, i.e., it limits the slow
behavior to the early boot stages, presumably due to eliminating heavy
map()/unmap() operations per each pixel line on the screen.

 [ ardb: ensure efifb is unmapped again unless keep_bootcon is in effect. ]
 [ mingo: speling fixes. ]

Signed-off-by: Andy Shevchenko 
Signed-off-by: Ard Biesheuvel 
Cc: Arvind Sankar 
Cc: Bhupesh Sharma 
Cc: Masayoshi Mizuma 
Cc: linux-efi@vger.kernel.org
Fixes: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation")
Link: https://lkml.kernel.org/r/20191206165542.31469-7-ardb@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

efi/gop: Fix memory leak in __gop_query32/64()

2020-01-12T11:21:16+00:00

[ Upstream commit ff397be685e410a59c34b21ce0c55d4daa466bb7 ]

efi_graphics_output_protocol::query_mode() returns info in
callee-allocated memory which must be freed by the caller, which
we aren't doing.

We don't actually need to call query_mode() in order to obtain the
info for the current graphics mode, which is already there in
gop->mode->info, so just access it directly in the setup_gop32/64()
functions.

Also nothing uses the size of the info structure, so don't update the
passed-in size (which is the size of the gop_handle table in bytes)
unnecessarily.

Signed-off-by: Arvind Sankar 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Shevchenko 
Cc: Bhupesh Sharma 
Cc: Masayoshi Mizuma 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191206165542.31469-5-ardb@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

efi/gop: Return EFI_SUCCESS if a usable GOP was found

2020-01-12T11:21:16+00:00

[ Upstream commit dbd89c303b4420f6cdb689fd398349fc83b059dd ]

If we've found a usable instance of the Graphics Output Protocol
(GOP) with a framebuffer, it is possible that one of the later EFI
calls fails while checking if any support console output. In this
case status may be an EFI error code even though we found a usable
GOP.

Fix this by explicitly return EFI_SUCCESS if a usable GOP has been
located.

Signed-off-by: Arvind Sankar 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Shevchenko 
Cc: Bhupesh Sharma 
Cc: Masayoshi Mizuma 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191206165542.31469-4-ardb@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

efi/gop: Return EFI_NOT_FOUND if there are no usable GOPs

2020-01-12T11:21:15+00:00

[ Upstream commit 6fc3cec30dfeee7d3c5db8154016aff9d65503c5 ]

If we don't find a usable instance of the Graphics Output Protocol
(GOP) because none of them have a framebuffer (i.e. they were all
PIXEL_BLT_ONLY), but all the EFI calls succeeded, we will return
EFI_SUCCESS even though we didn't find a usable GOP.

Fix this by explicitly returning EFI_NOT_FOUND if no usable GOPs are
found, allowing the caller to probe for UGA instead.

Signed-off-by: Arvind Sankar 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Shevchenko 
Cc: Bhupesh Sharma 
Cc: Masayoshi Mizuma 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191206165542.31469-3-ardb@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

efi: Don't attempt to map RCI2 config table if it doesn't exist

2020-01-09T09:20:07+00:00

[ Upstream commit a470552ee8965da0fe6fd4df0aa39c4cda652c7c ]

Commit:

  1c5fecb61255aa12 ("efi: Export Runtime Configuration Interface table to sysfs")

... added support for a Dell specific UEFI configuration table, but
failed to take into account that mapping the table should not be
attempted unless the table actually exists. If it doesn't exist,
the code usually fails silently unless pr_debug() prints are
enabled. However, on 32-bit PAE x86, the splat below is produced due
to the attempt to map the placeholder value EFI_INVALID_TABLE_ADDR
which we use for non-existing UEFI configuration tables, and which
equals ULONG_MAX.

   memremap attempted on mixed range 0x00000000ffffffff size: 0x1e
   WARNING: CPU: 1 PID: 1 at kernel/iomem.c:81 memremap+0x1a3/0x1c0
   Modules linked in:
   CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.2-smp-mine #1
   Hardware name: Hewlett-Packard HP Z400 Workstation/0B4Ch, BIOS 786G3 v03.61 03/05/2018
   EIP: memremap+0x1a3/0x1c0
  ...
   Call Trace:
    ? map_properties+0x473/0x473
    ? efi_rci2_sysfs_init+0x2c/0x154
    ? map_properties+0x473/0x473
    ? do_one_initcall+0x49/0x1d4
    ? parse_args+0x1e8/0x2a0
    ? do_early_param+0x7a/0x7a
    ? kernel_init_freeable+0x139/0x1c2
    ? rest_init+0x8e/0x8e
    ? kernel_init+0xd/0xf2
    ? ret_from_fork+0x2e/0x38

Fix this by checking whether the table exists before attempting to map it.

Reported-by: Richard Narron 
Tested-by: Richard Narron 
Signed-off-by: Ard Biesheuvel 
Cc: linux-efi@vger.kernel.org
Fixes: 1c5fecb61255aa12 ("efi: Export Runtime Configuration Interface table to sysfs")
Link: https://lkml.kernel.org/r/20191210090945.11501-2-ardb@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

firmware: arm_scmi: Avoid double free in error flow

2020-01-09T09:20:03+00:00

commit 8305e90a894f82c278c17e51a28459deee78b263 upstream.

If device_register() fails, both put_device() and kfree() are called,
ending with a double free of the scmi_dev.

Calling kfree() is needed only when a failure happens between the
allocation of the scmi_dev and its registration, so move it to there
and remove it from the error flow.

Fixes: 46edb8d1322c ("firmware: arm_scmi: provide the mandatory device release callback")
Signed-off-by: Wen Yang 
Signed-off-by: Sudeep Holla 
Signed-off-by: Greg Kroah-Hartman

efi/memreserve: Register reservations as 'reserved' in /proc/iomem

2019-12-31T15:46:06+00:00

commit ab0eb16205b43ece4c78e2259e681ff3d645ea66 upstream.

Memory regions that are reserved using efi_mem_reserve_persistent()
are recorded in a special EFI config table which survives kexec,
allowing the incoming kernel to honour them as well. However,
such reservations are not visible in /proc/iomem, and so the kexec
tools that load the incoming kernel and its initrd into memory may
overwrite these reserved regions before the incoming kernel has a
chance to reserve them from further use.

Address this problem by adding these reservations to /proc/iomem as
they are created. Note that reservations that are inherited from a
previous kernel are memblock_reserve()'d early on, so they are already
visible in /proc/iomem.

Tested-by: Masayoshi Mizuma 
Tested-by: Bhupesh Sharma 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Bhupesh Sharma 
Cc:  # v5.4+
Cc: Andy Shevchenko 
Cc: Arvind Sankar 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191206165542.31469-2-ardb@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman