Eric Lee / smarc-fsl-linux-kernel

08 Sep, 2020

1 commit

10 Jul, 2020

4 commits

31 Mar, 2020

1 commit

  • a776c270a   Merge branch 'efi-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip ... Browse Code »

    Pull EFI updates from Ingo Molnar:
    "The EFI changes in this cycle are much larger than usual, for two
    (positive) reasons:

    - The GRUB project is showing signs of life again, resulting in the
    introduction of the generic Linux/UEFI boot protocol, instead of
    x86 specific hacks which are increasingly difficult to maintain.
    There's hope that all future extensions will now go through that
    boot protocol.

    - Preparatory work for RISC-V EFI support.

    The main changes are:

    - Boot time GDT handling changes

    - Simplify handling of EFI properties table on arm64

    - Generic EFI stub cleanups, to improve command line handling, file
    I/O, memory allocation, etc.

    - Introduce a generic initrd loading method based on calling back
    into the firmware, instead of relying on the x86 EFI handover
    protocol or device tree.

    - Introduce a mixed mode boot method that does not rely on the x86
    EFI handover protocol either, and could potentially be adopted by
    other architectures (if another one ever surfaces where one
    execution mode is a superset of another)

    - Clean up the contents of 'struct efi', and move out everything that
    doesn't need to be stored there.

    - Incorporate support for UEFI spec v2.8A changes that permit
    firmware implementations to return EFI_UNSUPPORTED from UEFI
    runtime services at OS runtime, and expose a mask of which ones are
    supported or unsupported via a configuration table.

    - Partial fix for the lack of by-VA cache maintenance in the
    decompressor on 32-bit ARM.

    - Changes to load device firmware from EFI boot service memory
    regions

    - Various documentation updates and minor code cleanups and fixes"

    * 'efi-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (114 commits)
    efi/libstub/arm: Fix spurious message that an initrd was loaded
    efi/libstub/arm64: Avoid image_base value from efi_loaded_image
    partitions/efi: Fix partition name parsing in GUID partition entry
    efi/x86: Fix cast of image argument
    efi/libstub/x86: Use ULONG_MAX as upper bound for all allocations
    efi: Fix a mistype in comments mentioning efivar_entry_iter_begin()
    efi/libstub: Avoid linking libstub/lib-ksyms.o into vmlinux
    efi/x86: Preserve %ebx correctly in efi_set_virtual_address_map()
    efi/x86: Ignore the memory attributes table on i386
    efi/x86: Don't relocate the kernel unless necessary
    efi/x86: Remove extra headroom for setup block
    efi/x86: Add kernel preferred address to PE header
    efi/x86: Decompress at start of PE image load address
    x86/boot/compressed/32: Save the output address instead of recalculating it
    efi/libstub/x86: Deal with exit() boot service returning
    x86/boot: Use unsigned comparison for addresses
    efi/x86: Avoid using code32_start
    efi/x86: Make efi32_pe_entry() more readable
    efi/x86: Respect 32-bit ABI in efi32_pe_entry()
    efi/x86: Annotate the LOADED_IMAGE_PROTOCOL_GUID with SYM_DATA
    ...

    Linus Torvalds
     

20 Mar, 2020

1 commit

  • e4c2c0ff0   firmware: Add new platform fallback mechanism and firmware_request_platform() ... Browse Code »

    In some cases the platform's main firmware (e.g. the UEFI fw) may contain
    an embedded copy of device firmware which needs to be (re)loaded into the
    peripheral. Normally such firmware would be part of linux-firmware, but in
    some cases this is not feasible, for 2 reasons:

    1) The firmware is customized for a specific use-case of the chipset / use
    with a specific hardware model, so we cannot have a single firmware file
    for the chipset. E.g. touchscreen controller firmwares are compiled
    specifically for the hardware model they are used with, as they are
    calibrated for a specific model digitizer.

    2) Despite repeated attempts we have failed to get permission to
    redistribute the firmware. This is especially a problem with customized
    firmwares, these get created by the chip vendor for a specific ODM and the
    copyright may partially belong with the ODM, so the chip vendor cannot
    give a blanket permission to distribute these.

    This commit adds a new platform fallback mechanism to the firmware loader
    which will try to lookup a device fw copy embedded in the platform's main
    firmware if direct filesystem lookup fails.

    Drivers which need such embedded fw copies can enable this fallback
    mechanism by using the new firmware_request_platform() function.

    Note that for now this is only supported on EFI platforms and even on
    these platforms firmware_fallback_platform() only works if
    CONFIG_EFI_EMBEDDED_FIRMWARE is enabled (this gets selected by drivers
    which need this), in all other cases firmware_fallback_platform() simply
    always returns -ENOENT.

    Reported-by: Dave Olsthoorn
    Suggested-by: Peter Jones
    Acked-by: Luis Chamberlain
    Signed-off-by: Hans de Goede
    Link: https://lore.kernel.org/r/20200115163554.101315-5-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     

08 Mar, 2020

1 commit

  • f9834f18f   efi/libstub: Add libstub/mem.c to the documentation tree ... Browse Code »

    Let the description of the efi/libstub/mem.c functions appear in the kernel
    API documentation in the following chapters:

    The Linux driver implementer’s API guide
    Linux Firmware API
    UEFI Support
    UEFI stub library functions

    Acked-by: Jonathan Corbet
    Signed-off-by: Heinrich Schuchardt
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Ingo Molnar
    Link: https://lore.kernel.org/r/20200221035832.144960-1-xypron.glpk@gmx.de
    Link: https://lore.kernel.org/r/20200308080859.21568-9-ardb@kernel.org

    Heinrich Schuchardt
     

25 May, 2019

1 commit

  • e8d4f892b   docs: Fix a misdirected kerneldoc directive ... Browse Code »

    The stratix10 service layer documentation tried to include a kerneldoc
    comments for a nonexistent struct; leading to a "no structured comments
    found" message. Switch it to stratix10_svc_command_config_type, which
    appears at that spot in the sequence and was not included.

    Signed-off-by: Jonathan Corbet

    Jonathan Corbet
     

27 Nov, 2018

1 commit

07 Jul, 2018

1 commit

14 May, 2018

3 commits

26 Apr, 2018

1 commit

23 Apr, 2018

1 commit

23 Mar, 2018

1 commit

  • 5d42c96e1   firmware: add firmware_request_cache() to help with cache on reboot ... Browse Code »

    Some devices have an optimization in place to enable the firmware to
    be retaineed during a system reboot, so after reboot the device can skip
    requesting and loading the firmware. This can save up to 1s in load
    time. The mt7601u 802.11 device happens to be such a device.

    When these devices retain the firmware on a reboot and then suspend
    they can miss looking for the firmware on resume. To help with this we
    need a way to cache the firmware when such an optimization has taken
    place.

    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: Greg Kroah-Hartman

    Luis R. Rodriguez
     

20 Mar, 2018

1 commit

25 Jan, 2018

1 commit

10 Jan, 2018

1 commit

11 Sep, 2017

1 commit

  • f007cad15   Revert "firmware: add sanity check on shutdown/suspend" ... Browse Code »

    This reverts commit 81f95076281fdd3bc382e004ba1bce8e82fccbce.

    It causes random failures of firmware loading at resume time (well,
    random for me, it seems to be more reliable for others) because the
    firmware disabling is not actually synchronous with any particular
    resume event, and at least the btusb driver that uses a workqueue to
    load the firmware at resume seems to occasionally hit the "firmware
    loading is disabled" logic because the firmware loader hasn't gotten the
    resume event yet.

    Some kind of sanity check for not trying to load firmware when it's not
    possible might be a good thing, but this commit was not it.

    Greg seems to have silently suffered the same issue, and pointed to the
    likely culprit, and Gabriel C verified the revert fixed it for him too.

    Reported-by: Linus Torvalds
    Pointed-at-by: Greg Kroah-Hartman
    Tested-by: Gabriel C
    Cc: Luis R. Rodriguez
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

03 Jun, 2017

1 commit

  • 81f950762   firmware: add sanity check on shutdown/suspend ... Browse Code »

    The firmware API should not be used after we go to suspend
    and after we reboot/halt. The suspend/resume case is a bit
    complex, so this documents that so things are clearer.

    We want to know about users of the API in incorrect places so
    that their callers are corrected, so this also adds a warn
    for those cases.

    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: Greg Kroah-Hartman

    Luis R. Rodriguez
     

03 Apr, 2017

1 commit

11 Jan, 2017

1 commit

  • 113ccc383   firmware: revamp firmware documentation ... Browse Code »

    Understanding this code is getting out of control without any
    notes. Give the firmware_class driver a much needed documentation love,
    and while at it convert it to the new sphinx documentation format.

    v2: typos and small fixes

    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: Greg Kroah-Hartman

    Luis R. Rodriguez