20 Oct, 2020

1 commit

  • This reverts commit 4221d38de69f8c1d0e45141ca7737ef0cd17eb58.

    The above commit duplicates the mipi1, mipi1-pwm0, mipi1-i2c and lvds1
    power domain nodes, causing these errors to appear during boot:
    debugfs: Directory 'lvds1' with parent 'pm_genpd' already
    present!
    debugfs: Directory 'mipi1-i2c1' with parent 'pm_genpd'
    already present!
    debugfs: Directory 'mipi1-i2c0' with parent 'pm_genpd'
    already present!
    debugfs: Directory 'mipi1-pwm0' with parent 'pm_genpd'
    already present!
    debugfs: Directory 'mipi1' with parent 'pm_genpd' already
    present!

    Fixes: 0828343304 ("firmware: imx: scu-pd: add mipi lvds1 power
    domains")
    Signed-off-by: Robert Chiras

    Robert Chiras
     

08 Oct, 2020

1 commit

  • * tag 'v5.4.70': (3051 commits)
    Linux 5.4.70
    netfilter: ctnetlink: add a range check for l3/l4 protonum
    ep_create_wakeup_source(): dentry name can change under you...
    ...

    Conflicts:
    arch/arm/mach-imx/pm-imx6.c
    arch/arm64/boot/dts/freescale/imx8mm-evk.dts
    arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
    drivers/crypto/caam/caamalg.c
    drivers/gpu/drm/imx/dw_hdmi-imx.c
    drivers/gpu/drm/imx/imx-ldb.c
    drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
    drivers/mmc/host/sdhci-esdhc-imx.c
    drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
    drivers/net/ethernet/freescale/enetc/enetc.c
    drivers/net/ethernet/freescale/enetc/enetc_pf.c
    drivers/thermal/imx_thermal.c
    drivers/usb/cdns3/ep0.c
    drivers/xen/swiotlb-xen.c
    sound/soc/fsl/fsl_esai.c
    sound/soc/fsl/fsl_sai.c

    Signed-off-by: Jason Liu

    Jason Liu
     

05 Oct, 2020

3 commits

  • The structures used by imx_sc_rm_find_memreg() and
    imx_sc_rm_get_resource_owner() had a "misc" in their name
    but they are for the RM API.

    This patch replaces the "misc" part by "rm".

    Signed-off-by: Franck LENORMAND
    Reviewed-by: Iuliana Prodan
    Reviewed-by: Horia Geantă

    Franck LENORMAND
     
  • An error is detected by KASAN:
    [ 3.579068] BUG: KASAN: stack-out-of-bounds in imx_mu_generic_tx+0xf8/0x1e0
    [ 3.586048] Read of size 4 at addr ffff000010097914 by task swapper/0/1
    [ 3.592674]
    [ 3.594186] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.47-00127-gb7b4ad039c70-dirty #152
    [ 3.602556] Hardware name: Freescale i.MX8DXL EVK (DT)
    [ 3.607706] Call trace:
    [ 3.610178] dump_backtrace+0x0/0x200
    [ 3.613854] show_stack+0x14/0x20
    [ 3.617189] dump_stack+0xf4/0x150
    [ 3.620614] print_address_description.isra.9+0x6c/0x3b8
    [ 3.625951] __kasan_report+0x12c/0x23c
    [ 3.629806] kasan_report+0xc/0x18
    [ 3.633230] __asan_load4+0x94/0xb8
    [ 3.636744] imx_mu_generic_tx+0xf8/0x1e0
    [ 3.640776] imx_mu_send_data+0x5c/0x70
    [ 3.644637] msg_submit+0x128/0x1d0
    [ 3.648152] mbox_send_message+0xb8/0x1c8
    [ 3.652180] imx_scu_ipc_write+0x94/0x138
    [ 3.656205] imx_scu_call_rpc+0x160/0x308
    [ 3.660241] imx_sc_rm_get_resource_owner+0x94/0xf0
    [ 3.665139] seco_mu_probe+0x10c/0x638
    [ 3.668914] platform_drv_probe+0x70/0xd8
    [ 3.672945] really_probe+0x174/0x478
    [ 3.676626] driver_probe_device+0x7c/0x148
    [ 3.680832] device_driver_attach+0x94/0xa0
    [ 3.685035] __driver_attach+0xa4/0x110
    [ 3.688893] bus_for_each_dev+0xe8/0x158
    [ 3.692839] driver_attach+0x30/0x40
    [ 3.696432] bus_add_driver+0x234/0x2f0
    [ 3.700292] driver_register+0xbc/0x1d0
    [ 3.704155] __platform_driver_register+0x7c/0x88
    [ 3.708889] seco_mu_driver_init+0x18/0x20
    [ 3.713009] do_one_initcall+0xb4/0x254
    [ 3.716870] kernel_init_freeable+0x24c/0x2f8
    [ 3.721256] kernel_init+0x10/0x118
    [ 3.724761] ret_from_fork+0x10/0x18
    [ 3.728346]
    [ 3.729844] The buggy address belongs to the page:
    [ 3.734658] page:fffffe00002025c0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0
    [ 3.742943] flags: 0xffff00000000000()
    [ 3.746728] raw: 0ffff00000000000 fffffe00002025c8 fffffe00002025c8 0000000000000000
    [ 3.754506] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    [ 3.762267] page dumped because: kasan: bad access detected
    [ 3.767850]
    [ 3.769354] addr ffff000010097914 is located in stack of task swapper/0/1 at offset 36 in frame:
    [ 3.778162] imx_sc_rm_get_resource_owner+0x0/0xf0
    [ 3.782970]
    [ 3.784472] this frame has 1 object:
    [ 3.788065] [32, 38) 'msg'
    [ 3.788070]
    [ 3.792358] Memory state around the buggy address:
    [ 3.797174] ffff000010097800: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 f3 f3
    [ 3.804419] ffff000010097880: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
    [ 3.811666] >ffff000010097900: f1 f1 06 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
    [ 3.818899] ^
    [ 3.822669] ffff000010097980: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f2
    [ 3.829914] ffff000010097a00: f2 f2 f2 f2 f2 f2 04 f2 f2 f2 00 00 00 00 00 00
    [ 3.837151] ==================================================================

    It happens because some structure are not packed as expected by the communication
    protocol with the SCFW:
    - imx_sc_msg_seco_get_build_id
    - imx_sc_msg_seco_sab_msg

    This patch adds the tag "__packed __aligned(4)" to enforce
    the 4 byte alignment of the structures by the compiler

    Fixes: 2ccb9a596aab (SSI-87: firmware: imx: Add APIs required for secvio)
    Fixes: 9edf1255f89b (LF-824: fw: imx: scu: Add SECO API)
    Signed-off-by: Franck LENORMAND
    Reviewed-by: Iuliana Prodan
    Reviewed-by: Horia Geantă

    Franck LENORMAND
     
  • An error is detected by KASAN:
    [ 3.579068] BUG: KASAN: stack-out-of-bounds in imx_mu_generic_tx+0xf8/0x1e0
    [ 3.586048] Read of size 4 at addr ffff000010097914 by task swapper/0/1
    [ 3.592674]
    [ 3.594186] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.47-00127-gb7b4ad039c70-dirty #152
    [ 3.602556] Hardware name: Freescale i.MX8DXL EVK (DT)
    [ 3.607706] Call trace:
    [ 3.610178] dump_backtrace+0x0/0x200
    [ 3.613854] show_stack+0x14/0x20
    [ 3.617189] dump_stack+0xf4/0x150
    [ 3.620614] print_address_description.isra.9+0x6c/0x3b8
    [ 3.625951] __kasan_report+0x12c/0x23c
    [ 3.629806] kasan_report+0xc/0x18
    [ 3.633230] __asan_load4+0x94/0xb8
    [ 3.636744] imx_mu_generic_tx+0xf8/0x1e0
    [ 3.640776] imx_mu_send_data+0x5c/0x70
    [ 3.644637] msg_submit+0x128/0x1d0
    [ 3.648152] mbox_send_message+0xb8/0x1c8
    [ 3.652180] imx_scu_ipc_write+0x94/0x138
    [ 3.656205] imx_scu_call_rpc+0x160/0x308
    [ 3.660241] imx_sc_rm_get_resource_owner+0x94/0xf0
    [ 3.665139] seco_mu_probe+0x10c/0x638
    [ 3.668914] platform_drv_probe+0x70/0xd8
    [ 3.672945] really_probe+0x174/0x478
    [ 3.676626] driver_probe_device+0x7c/0x148
    [ 3.680832] device_driver_attach+0x94/0xa0
    [ 3.685035] __driver_attach+0xa4/0x110
    [ 3.688893] bus_for_each_dev+0xe8/0x158
    [ 3.692839] driver_attach+0x30/0x40
    [ 3.696432] bus_add_driver+0x234/0x2f0
    [ 3.700292] driver_register+0xbc/0x1d0
    [ 3.704155] __platform_driver_register+0x7c/0x88
    [ 3.708889] seco_mu_driver_init+0x18/0x20
    [ 3.713009] do_one_initcall+0xb4/0x254
    [ 3.716870] kernel_init_freeable+0x24c/0x2f8
    [ 3.721256] kernel_init+0x10/0x118
    [ 3.724761] ret_from_fork+0x10/0x18
    [ 3.728346]
    [ 3.729844] The buggy address belongs to the page:
    [ 3.734658] page:fffffe00002025c0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0
    [ 3.742943] flags: 0xffff00000000000()
    [ 3.746728] raw: 0ffff00000000000 fffffe00002025c8 fffffe00002025c8 0000000000000000
    [ 3.754506] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    [ 3.762267] page dumped because: kasan: bad access detected
    [ 3.767850]
    [ 3.769354] addr ffff000010097914 is located in stack of task swapper/0/1 at offset 36 in frame:
    [ 3.778162] imx_sc_rm_get_resource_owner+0x0/0xf0
    [ 3.782970]
    [ 3.784472] this frame has 1 object:
    [ 3.788065] [32, 38) 'msg'
    [ 3.788070]
    [ 3.792358] Memory state around the buggy address:
    [ 3.797174] ffff000010097800: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 f3 f3
    [ 3.804419] ffff000010097880: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
    [ 3.811666] >ffff000010097900: f1 f1 06 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
    [ 3.818899] ^
    [ 3.822669] ffff000010097980: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f2
    [ 3.829914] ffff000010097a00: f2 f2 f2 f2 f2 f2 04 f2 f2 f2 00 00 00 00 00 00
    [ 3.837151] ==================================================================

    It happens because some structure are not packed as expected by the communication
    protocol with the SCFW:
    - imx_sc_msg_rm_get_resource_owner
    - imx_sc_msg_rm_find_memreg

    This patch adds the tag "__packed __aligned(4)" to enforce
    the 4 byte alignment of the structures by the compiler

    Fixes: 10237c7bcb17 (LF-824: fw: imx: scu: Add missing APIs)
    Signed-off-by: Franck LENORMAND
    Reviewed-by: Iuliana Prodan
    Reviewed-by: Horia Geantă

    Franck LENORMAND
     

01 Oct, 2020

1 commit

  • [ Upstream commit 54f529a6806c9710947a4f2cdc15d6ea54121ccd ]

    SDEI has private events that need registering and enabling on each CPU.
    CPUs can come and go while we are trying to do this. SDEI tries to avoid
    these problems by setting the reregister flag before the register call,
    so any CPUs that come online register the event too. Sticking plaster
    like this doesn't work, as if the register call fails, a CPU that
    subsequently comes online will register the event before reregister
    is cleared.

    Take cpus_read_lock() around the register and enable calls. We don't
    want surprise CPUs to do the wrong thing if they race with these calls
    failing.

    Signed-off-by: James Morse
    Signed-off-by: Catalin Marinas
    Signed-off-by: Sasha Levin

    James Morse
     

23 Sep, 2020

1 commit


22 Sep, 2020

1 commit


26 Aug, 2020

1 commit

  • commit 98086df8b70c06234a8f4290c46064e44dafa0ed upstream.

    destroy_workqueue() should be called to destroy efi_rts_wq
    when efisubsys_init() init resources fails.

    Cc:
    Reported-by: Hulk Robot
    Signed-off-by: Li Heng
    Link: https://lore.kernel.org/r/1595229738-10087-1-git-send-email-liheng40@huawei.com
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Greg Kroah-Hartman

    Li Heng
     

19 Aug, 2020

1 commit

  • [ Upstream commit e0f1a30cf184821499eeb67daedd7a3f21bbcb0b ]

    When, at probe time, an SCMI communication failure inhibits the capacity
    to query power domains states, such domains should be skipped.

    Registering partially initialized SCMI power domains with genpd will
    causes kernel panic.

    arm-scmi timed out in resp(caller: scmi_power_state_get+0xa4/0xd0)
    scmi-power-domain scmi_dev.2: failed to get state for domain 9
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    Mem abort info:
    ESR = 0x96000006
    EC = 0x25: DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
    Data abort info:
    ISV = 0, ISS = 0x00000006
    CM = 0, WnR = 0
    user pgtable: 4k pages, 48-bit VAs, pgdp=00000009f3691000
    [0000000000000000] pgd=00000009f1ca0003, p4d=00000009f1ca0003, pud=00000009f35ea003, pmd=0000000000000000
    Internal error: Oops: 96000006 [#1] PREEMPT SMP
    CPU: 2 PID: 381 Comm: bash Not tainted 5.8.0-rc1-00011-gebd118c2cca8 #2
    Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jan 3 2020
    Internal error: Oops: 96000006 [#1] PREEMPT SMP
    pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--)
    pc : of_genpd_add_provider_onecell+0x98/0x1f8
    lr : of_genpd_add_provider_onecell+0x48/0x1f8
    Call trace:
    of_genpd_add_provider_onecell+0x98/0x1f8
    scmi_pm_domain_probe+0x174/0x1e8
    scmi_dev_probe+0x90/0xe0
    really_probe+0xe4/0x448
    driver_probe_device+0xfc/0x168
    device_driver_attach+0x7c/0x88
    bind_store+0xe8/0x128
    drv_attr_store+0x2c/0x40
    sysfs_kf_write+0x4c/0x60
    kernfs_fop_write+0x114/0x230
    __vfs_write+0x24/0x50
    vfs_write+0xbc/0x1e0
    ksys_write+0x70/0xf8
    __arm64_sys_write+0x24/0x30
    el0_svc_common.constprop.3+0x94/0x160
    do_el0_svc+0x2c/0x98
    el0_sync_handler+0x148/0x1a8
    el0_sync+0x158/0x180

    Do not register any power domain that failed to be queried with genpd.

    Fixes: 898216c97ed2 ("firmware: arm_scmi: add device power domain support using genpd")
    Link: https://lore.kernel.org/r/20200619220330.12217-1-cristian.marussi@arm.com
    Signed-off-by: Cristian Marussi
    Signed-off-by: Sudeep Holla
    Signed-off-by: Sasha Levin

    Cristian Marussi
     

13 Aug, 2020

1 commit


11 Aug, 2020

1 commit

  • [ Upstream commit fe3c60684377d5ad9b0569b87ed3e26e12c8173b ]

    kobject_init_and_add() takes reference even when it fails.
    If this function returns an error, kobject_put() must be called to
    properly clean up the memory associated with the object.
    Callback function fw_cfg_sysfs_release_entry() in kobject_put()
    can handle the pointer "entry" properly.

    Signed-off-by: Qiushi Wu
    Link: https://lore.kernel.org/r/20200613190533.15712-1-wu000273@umn.edu
    Signed-off-by: Michael S. Tsirkin
    Signed-off-by: Sasha Levin

    Qiushi Wu
     

29 Jul, 2020

1 commit

  • [ Upstream commit c377e67c6271954969384f9be1b1b71de13eba30 ]

    The CPU mask (@tmp) should be released on failing to allocate
    @cpu_groups or any of its elements. Otherwise, it leads to memory
    leakage because the CPU mask variable is dynamically allocated
    when CONFIG_CPUMASK_OFFSTACK is enabled.

    Signed-off-by: Gavin Shan
    Reviewed-by: Sudeep Holla
    Link: https://lore.kernel.org/r/20200630075227.199624-1-gshan@redhat.com
    Signed-off-by: Will Deacon
    Signed-off-by: Sasha Levin

    Gavin Shan
     

09 Jul, 2020

1 commit

  • commit 435d1a471598752446a72ad1201b3c980526d869 upstream.

    In most cases, such as CONFIG_ACPI_CUSTOM_DSDT and
    CONFIG_ACPI_TABLE_UPGRADE, boot-time modifications to firmware tables
    are tied to specific Kconfig options. Currently this is not the case
    for modifying the ACPI SSDT via the efivar_ssdt kernel command line
    option and associated EFI variable.

    This patch adds CONFIG_EFI_CUSTOM_SSDT_OVERLAYS, which defaults
    disabled, in order to allow enabling or disabling that feature during
    the build.

    Cc:
    Signed-off-by: Peter Jones
    Link: https://lore.kernel.org/r/20200615202408.2242614-1-pjones@redhat.com
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Greg Kroah-Hartman

    Peter Jones
     

01 Jul, 2020

1 commit

  • [ Upstream commit 4ddf4739be6e375116c375f0a68bf3893ffcee21 ]

    kobject_init_and_add() takes reference even when it fails.
    If this function returns an error, kobject_put() must be called to
    properly clean up the memory associated with the object. Previous
    commit "b8eb718348b8" fixed a similar problem.

    Fixes: 0bb549052d33 ("efi: Add esrt support")
    Signed-off-by: Qiushi Wu
    Link: https://lore.kernel.org/r/20200528183804.4497-1-wu000273@umn.edu
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Sasha Levin

    Qiushi Wu
     

24 Jun, 2020

2 commits

  • [ Upstream commit 89f12d6509bff004852c51cb713a439a86816b24 ]

    '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: edbee095fafb ("firmware: imx: add SCU firmware driver support")
    Signed-off-by: Wei Yongjun
    Reviewed-by: Dong Aisheng
    Signed-off-by: Shawn Guo
    Signed-off-by: Sasha Levin

    Wei Yongjun
     
  • [ Upstream commit 459b1f86f1cba7de813fbc335df476c111feec22 ]

    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
    Signed-off-by: Christoph Hellwig
    Link: https://lore.kernel.org/r/20200414123136.441454-1-hch@lst.de
    Signed-off-by: Bjorn Andersson
    Signed-off-by: Sasha Levin

    Christoph Hellwig
     

22 Jun, 2020

1 commit

  • [ Upstream commit f77767ed5f4d398b29119563155e4ece2dfeee13 ]

    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
    Cc: Peter Collingbourne
    Cc: Sami Tolvanen
    Reported-by: Arnd Bergmann
    Suggested-by: Fangrui Song
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Sasha Levin

    Ard Biesheuvel
     

19 Jun, 2020

1 commit

  • * tag 'v5.4.47': (2193 commits)
    Linux 5.4.47
    KVM: arm64: Save the host's PtrAuth keys in non-preemptible context
    KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception
    ...

    Conflicts:
    arch/arm/boot/dts/imx6qdl.dtsi
    arch/arm/mach-imx/Kconfig
    arch/arm/mach-imx/common.h
    arch/arm/mach-imx/suspend-imx6.S
    arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
    arch/powerpc/include/asm/cacheflush.h
    drivers/cpufreq/imx6q-cpufreq.c
    drivers/dma/imx-sdma.c
    drivers/edac/synopsys_edac.c
    drivers/firmware/imx/imx-scu.c
    drivers/net/ethernet/freescale/fec.h
    drivers/net/ethernet/freescale/fec_main.c
    drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
    drivers/net/phy/phy_device.c
    drivers/perf/fsl_imx8_ddr_perf.c
    drivers/usb/cdns3/gadget.c
    drivers/usb/dwc3/gadget.c
    include/uapi/linux/dma-buf.h

    Signed-off-by: Jason Liu

    Jason Liu
     

17 Jun, 2020

4 commits

  • [ Upstream commit f5f27b79eab80de0287c243a22169e4876b08d5e ]

    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
    Reviewed-by: Leonard Crestez
    Signed-off-by: Leonard Crestez
    Cc: stable@vger.kernel.org
    Reviewed-by: Dong Aisheng
    Signed-off-by: Shawn Guo
    Signed-off-by: Sasha Levin

    Franck LENORMAND
     
  • [ Upstream commit f25a066d1a07affb7bea4e5d9c179c3338338e23 ]

    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
    Signed-off-by: Shawn Guo
    Signed-off-by: Sasha Levin

    Peng Fan
     
  • [ Upstream commit cf0fd404455ce13850cc15423a3c2958933de384 ]

    The imx_scu_call_rpc function returns the result inside the
    same "msg" struct containing the transmitted message. This is
    implemented by holding a pointer to msg (which is usually on the stack)
    in sc_imx_rpc and writing to it from imx_scu_rx_callback.

    This means that if the have_resp parameter is incorrect or SCU sends an
    unexpected response for any reason the most likely result is kernel stack
    corruption.

    Fix this by only setting sc_imx_rpc.msg for the duration of the
    imx_scu_call_rpc call and warning in imx_scu_rx_callback if unset.

    Print the unexpected response data to help debugging.

    Signed-off-by: Leonard Crestez
    Acked-by: Anson Huang
    Signed-off-by: Shawn Guo
    Signed-off-by: Sasha Levin

    Leonard Crestez
     
  • commit d8bd8c6e2cfab8b78b537715255be8d7557791c0 upstream.

    The documentation provided by kobject_init_and_add() clearly spells out
    the need to call kobject_put() on the kobject if an error is returned.
    Add this missing call to the error path.

    Cc:
    Reported-by: 亿一
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Greg Kroah-Hartman

    Ard Biesheuvel
     

11 Jun, 2020

3 commits


30 May, 2020

1 commit


27 May, 2020

1 commit

  • [ Upstream commit b4f1874c62168159fdb419ced4afc77c1b51c475 ]

    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: c46f3405692de ("tpm: Reserve the TPM final events table")
    Fixes: 166a2809d65b2 ("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
    Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yhuel@gmail.com
    Reviewed-by: Javier Martinez Canillas
    Reviewed-by: Jerry Snitselaar
    Reviewed-by: Matthew Garrett
    [ardb: warn when final events table is missing or in the wrong format]
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Sasha Levin

    Loïc Yhuel
     

22 May, 2020

2 commits


20 May, 2020

1 commit

  • commit e99332e7b4cda6e60f5b5916cf9943a79dbef902 upstream.

    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
    Signed-off-by: Greg Kroah-Hartman

    Linus Torvalds
     

24 Apr, 2020

1 commit


23 Apr, 2020

1 commit

  • At boot, the driver can print error messages because it has been
    deferred so they should not be printed.
    The driver also prints the version of the SECO which is not useful.

    This patch fixes the print of messages due to defer and remove the
    print of the SECO version.

    Signed-off-by: Franck LENORMAND
    Reviewed-by: Horia Geantă

    Franck LENORMAND
     

22 Apr, 2020

2 commits


17 Apr, 2020

2 commits

  • [ Upstream commit dd09fad9d2caad2325a39b766ce9e79cfc690184 ]

    Commit:

    3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures")

    moved the call to efi_memattr_init() from ARM specific to the generic
    EFI init code, in order to be able to apply the restricted permissions
    described in that table on x86 as well.

    We never enabled this feature fully on i386, and so mapping and
    reserving this table is pointless. However, due to the early call to
    memblock_reserve(), the memory bookkeeping gets confused to the point
    where it produces the splat below when we try to map the memory later
    on:

    ------------[ cut here ]------------
    ioremap on RAM at 0x3f251000 - 0x3fa1afff
    WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:166 __ioremap_caller ...
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0 #48
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
    EIP: __ioremap_caller.constprop.0+0x249/0x260
    Code: 90 0f b7 05 4e 38 40 de 09 45 e0 e9 09 ff ff ff 90 8d 45 ec c6 05 ...
    EAX: 00000029 EBX: 00000000 ECX: de59c228 EDX: 00000001
    ESI: 3f250fff EDI: 00000000 EBP: de3edf20 ESP: de3edee0
    DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200296
    CR0: 80050033 CR2: ffd17000 CR3: 1e58c000 CR4: 00040690
    Call Trace:
    ioremap_cache+0xd/0x10
    ? old_map_region+0x72/0x9d
    old_map_region+0x72/0x9d
    efi_map_region+0x8/0xa
    efi_enter_virtual_mode+0x260/0x43b
    start_kernel+0x329/0x3aa
    i386_start_kernel+0xa7/0xab
    startup_32_smp+0x164/0x168
    ---[ end trace e15ccf6b9f356833 ]---

    Let's work around this by disregarding the memory attributes table
    altogether on i386, which does not result in a loss of functionality
    or protection, given that we never consumed the contents.

    Fixes: 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE ... ")
    Tested-by: Arvind Sankar
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Ingo Molnar
    Link: https://lore.kernel.org/r/20200304165917.5893-1-ardb@kernel.org
    Link: https://lore.kernel.org/r/20200308080859.21568-21-ardb@kernel.org
    Signed-off-by: Sasha Levin

    Ard Biesheuvel
     
  • [ Upstream commit 6ded0b61cf638bf9f8efe60ab8ba23db60ea9763 ]

    SDEI has private events that must be registered on each CPU. When
    CPUs come and go they must re-register and re-enable their private
    events. Each event has flags to indicate whether this should happen
    to protect against an event being registered on a CPU coming online,
    while all the others are unregistering the event.

    These flags are protected by the sdei_list_lock spinlock, because
    the cpuhp callbacks can't take the mutex.

    Hibernate needs to unregister all events, but keep the in-memory
    re-register and re-enable as they are. sdei_unregister_shared()
    takes the spinlock to walk the list, then calls _sdei_event_unregister()
    on each shared event. _sdei_event_unregister() tries to take the
    same spinlock to update re-register and re-enable. This doesn't go
    so well.

    Push the re-register and re-enable updates out to their callers.
    sdei_unregister_shared() doesn't want these values updated, so
    doesn't need to do anything.

    This also fixes shared events getting lost over hibernate as this
    path made them look unregistered.

    Fixes: da351827240e ("firmware: arm_sdei: Add support for CPU and system power states")
    Reported-by: Liguang Zhang
    Signed-off-by: James Morse
    Signed-off-by: Catalin Marinas
    Signed-off-by: Sasha Levin

    James Morse
     

09 Apr, 2020

1 commit


30 Mar, 2020

1 commit


18 Mar, 2020

1 commit

  • commit d6c066fda90d578aacdf19771a027ed484a79825 upstream.

    Add a sanity check to efivar_store_raw() the same way
    efivar_{attr,size,data}_read() and efivar_show_raw() have it.

    Signed-off-by: Vladis Dronov
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Ingo Molnar
    Cc:
    Link: https://lore.kernel.org/r/20200305084041.24053-3-vdronov@redhat.com
    Link: https://lore.kernel.org/r/20200308080859.21568-25-ardb@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Vladis Dronov