1. 26 Mar, 2018 5 commits
    • Suzuki K Poulose's avatar
      arm64: capabilities: Prepare for fine grained capabilities · 143ba05d
      Suzuki K Poulose authored
      We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
      to the userspace and the CPU hwcaps used by the kernel, which
      include cpu features and CPU errata work arounds. Capabilities
      have some properties that decide how they should be treated :
      
       1) Detection, i.e scope : A cap could be "detected" either :
          - if it is present on at least one CPU (SCOPE_LOCAL_CPU)
      	Or
          - if it is present on all the CPUs (SCOPE_SYSTEM)
      
       2) When is it enabled ? - A cap is treated as "enabled" when the
        system takes some action based on whether the capability is detected or
        not. e.g, setting some control register, patching the kernel code.
        Right now, we treat all caps are enabled at boot-time, after all
        the CPUs are brought up by the kernel. But there are certain caps,
        which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
        and kernel starts using them, even before the secondary CPUs are brought
        up. We would need a way to describe this for each capability.
      
       3) Conflict on a late CPU - When a CPU is brought up, it is checked
        against the caps that are known to be enabled on the system (via
        verify_local_cpu_capabilities()). Based on the state of the capability
        on the CPU vs. that of System we could have the following combinations
        of conflict.
      
      	x-----------------------------x
      	| Type	| System   | Late CPU |
      	------------------------------|
      	|  a    |   y      |    n     |
      	------------------------------|
      	|  b    |   n      |    y     |
      	x-----------------------------x
      
        Case (a) is not permitted for caps which are system features, which the
        system expects all the CPUs to have (e.g VHE). While (a) is ignored for
        all errata work arounds. However, there could be exceptions to the plain
        filtering approach. e.g, KPTI is an optional feature for a late CPU as
        long as the system already enables it.
      
        Case (b) is not permitted for errata work arounds which requires some
        work around, which cannot be delayed. And we ignore (b) for features.
        Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
        are too late to enable it (because we change the allocation of ASIDs
        etc).
      
      So this calls for a lot more fine grained behavior for each capability.
      And if we define all the attributes to control their behavior properly,
      we may be able to use a single table for the CPU hwcaps (which cover
      errata and features, not the ELF HWCAPs). This is a prepartory step
      to get there. More bits would be added for the properties listed above.
      
      We are going to use a bit-mask to encode all the properties of a
      capabilities. This patch encodes the "SCOPE" of the capability.
      
      As such there is no change in how the capabilities are treated.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      143ba05d
    • Suzuki K Poulose's avatar
      arm64: capabilities: Move errata processing code · 1e89baed
      Suzuki K Poulose authored
      We have errata work around processing code in cpu_errata.c,
      which calls back into helpers defined in cpufeature.c. Now
      that we are going to make the handling of capabilities
      generic, by adding the information to each capability,
      move the errata work around specific processing code.
      No functional changes.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1e89baed
    • Suzuki K Poulose's avatar
      arm64: capabilities: Move errata work around check on boot CPU · 5e91107b
      Suzuki K Poulose authored
      We trigger CPU errata work around check on the boot CPU from
      smp_prepare_boot_cpu() to make sure that we run the checks only
      after the CPU feature infrastructure is initialised. While this
      is correct, we can also do this from init_cpu_features() which
      initilises the infrastructure, and is called only on the
      Boot CPU. This helps to consolidate the CPU capability handling
      to cpufeature.c. No functional changes.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5e91107b
    • Dave Martin's avatar
      arm64: capabilities: Update prototype for enable call back · c0cda3b8
      Dave Martin authored
      We issue the enable() call back for all CPU hwcaps capabilities
      available on the system, on all the CPUs. So far we have ignored
      the argument passed to the call back, which had a prototype to
      accept a "void *" for use with on_each_cpu() and later with
      stop_machine(). However, with commit 0a0d111d
      ("arm64: cpufeature: Pass capability structure to ->enable callback"),
      there are some users of the argument who wants the matching capability
      struct pointer where there are multiple matching criteria for a single
      capability. Clean up the declaration of the call back to make it clear.
      
       1) Renamed to cpu_enable(), to imply taking necessary actions on the
          called CPU for the entry.
       2) Pass const pointer to the capability, to allow the call back to
          check the entry. (e.,g to check if any action is needed on the CPU)
       3) We don't care about the result of the call back, turning this to
          a void.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Acked-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarDave Martin <dave.martin@arm.com>
      [suzuki: convert more users, rename call back and drop results]
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c0cda3b8
    • Dave Martin's avatar
      arm64/sve: Document firmware support requirements in Kconfig · 5043694e
      Dave Martin authored
      Use of SVE by EL2 and below requires explicit support in the
      firmware.  There is no means to hide the presence of SVE from EL2,
      so a kernel configured with CONFIG_ARM64_SVE=y will typically not
      work correctly on SVE capable hardware unless the firmware does
      include the appropriate support.
      
      This is not expected to pose a problem in the wild, since platform
      integrators are responsible for ensuring that they ship up-to-date
      firmware to support their hardware.  However, developers may hit
      the issue when using mismatched compoments.
      
      In order to draw attention to the issue and how to solve it, this
      patch adds some Kconfig text giving a brief explanation and details
      of compatible firmware versions.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5043694e
  2. 20 Mar, 2018 2 commits
    • Dave Martin's avatar
      arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE · af4a81b9
      Dave Martin authored
      Currently a SIGFPE delivered in response to a floating-point
      exception trap may have si_code set to 0 on arm64.  As reported by
      Eric, this is a bad idea since this is the value of SI_USER -- yet
      this signal is definitely not the result of kill(2), tgkill(2) etc.
      and si_uid and si_pid make limited sense whereas we do want to
      yield a value for si_addr (which doesn't exist for SI_USER).
      
      It's not entirely clear whether the architecure permits a
      "spurious" fp exception trap where none of the exception flag bits
      in ESR_ELx is set.  (IMHO the architectural intent is to forbid
      this.)  However, it does permit those bits to contain garbage if
      the TFV bit in ESR_ELx is 0.  That case isn't currently handled at
      all and may result in si_code == 0 or si_code containing a FPE_FLT*
      constant corresponding to an exception that did not in fact happen.
      
      There is nothing sensible we can return for si_code in such cases,
      but SI_USER is certainly not appropriate and will lead to violation
      of legitimate userspace assumptions.
      
      This patch allocates a new si_code value FPE_UNKNOWN that at least
      does not conflict with any existing SI_* or FPE_* code, and yields
      this in si_code for undiagnosable cases.  This is probably the best
      simplicity/incorrectness tradeoff achieveable without relying on
      implementation-dependent features or adding a lot of code.  In any
      case, there appears to be no perfect solution possible that would
      justify a lot of effort here.
      
      Yielding FPE_UNKNOWN when some well-defined fp exception caused the
      trap is a violation of POSIX, but this is forced by the
      architecture.  We have no realistic prospect of yielding the
      correct code in such cases.  At present I am not aware of any ARMv8
      implementation that supports trapped floating-point exceptions in
      any case.
      
      The new code may be applicable to other architectures for similar
      reasons.
      
      No attempt is made to provide ESR_ELx to userspace in the signal
      frame, since architectural limitations mean that it is unlikely to
      provide much diagnostic value, doesn't benefit existing software
      and would create ABI with no proven purpose.  The existing
      mechanism for passing it also has problems of its own which may
      result in the wrong value being passed to userspace due to
      interaction with mm faults.  The implied rework does not appear
      justified.
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Reported-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      af4a81b9
    • Will Deacon's avatar
      Merge branch 'siginfo-next' of... · 4c0ca49e
      Will Deacon authored
      Merge branch 'siginfo-next' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace into aarch64/for-next/core
      
      Pull in pending siginfo changes from Eric Biederman as we depend on
      the definition of FPE_FLTUNK for cleaning up our floating-point exception
      signal delivery (which is currently broken and using FPE_FIXME).
      4c0ca49e
  3. 19 Mar, 2018 4 commits
  4. 15 Mar, 2018 1 commit
  5. 09 Mar, 2018 6 commits
    • Will Deacon's avatar
      Merge tag 'acpi/iort-for-v4.17' of... · 654c39c7
      Will Deacon authored
      Merge tag 'acpi/iort-for-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux into aarch64/for-next/core
      
      Three ACPI IORT clean-up patches aimed at v4.17 release cycle:
      
      - Removal of IORT linker script entry re-introduced by mistake by clocksource
        drivers refactoring (J.He)
      - Two ACPICA guards removal of previously introduced guards to prevent
        ACPICA<->kernel patches dependencies (L.Pieralisi)
      654c39c7
    • Dave Martin's avatar
      arm64: signal: Ensure si_code is valid for all fault signals · af40ff68
      Dave Martin authored
      Currently, as reported by Eric, an invalid si_code value 0 is
      passed in many signals delivered to userspace in response to faults
      and other kernel errors.  Typically 0 is passed when the fault is
      insufficiently diagnosable or when there does not appear to be any
      sensible alternative value to choose.
      
      This appears to violate POSIX, and is intuitively wrong for at
      least two reasons arising from the fact that 0 == SI_USER:
      
       1) si_code is a union selector, and SI_USER (and si_code <= 0 in
          general) implies the existence of a different set of fields
          (siginfo._kill) from that which exists for a fault signal
          (siginfo._sigfault).  However, the code raising the signal
          typically writes only the _sigfault fields, and the _kill
          fields make no sense in this case.
      
          Thus when userspace sees si_code == 0 (SI_USER) it may
          legitimately inspect fields in the inactive union member _kill
          and obtain garbage as a result.
      
          There appears to be software in the wild relying on this,
          albeit generally only for printing diagnostic messages.
      
       2) Software that wants to be robust against spurious signals may
          discard signals where si_code == SI_USER (or <= 0), or may
          filter such signals based on the si_uid and si_pid fields of
          siginfo._sigkill.  In the case of fault signals, this means
          that important (and usually fatal) error conditions may be
          silently ignored.
      
      In practice, many of the faults for which arm64 passes si_code == 0
      are undiagnosable conditions such as exceptions with syndrome
      values in ESR_ELx to which the architecture does not yet assign any
      meaning, or conditions indicative of a bug or error in the kernel
      or system and thus that are unrecoverable and should never occur in
      normal operation.
      
      The approach taken in this patch is to translate all such
      undiagnosable or "impossible" synchronous fault conditions to
      SIGKILL, since these are at least probably localisable to a single
      process.  Some of these conditions should really result in a kernel
      panic, but due to the lack of diagnostic information it is
      difficult to be certain: this patch does not add any calls to
      panic(), but this could change later if justified.
      
      Although si_code will not reach userspace in the case of SIGKILL,
      it is still desirable to pass a nonzero value so that the common
      siginfo handling code can detect incorrect use of si_code == 0
      without false positives.  In this case the si_code dependent
      siginfo fields will not be correctly initialised, but since they
      are not passed to userspace I deem this not to matter.
      
      A few faults can reasonably occur in realistic userspace scenarios,
      and _should_ raise a regular, handleable (but perhaps not
      ignorable/blockable) signal: for these, this patch attempts to
      choose a suitable standard si_code value for the raised signal in
      each case instead of 0.
      
      arm64 was the only arch to define a BUS_FIXME code, so after this
      patch nobody defines it.  This patch therefore also removes the
      relevant code from siginfo_layout().
      
      Cc: James Morse <james.morse@arm.com>
      Reported-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      af40ff68
    • Shanker Donthineni's avatar
      arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC · 6ae4b6e0
      Shanker Donthineni authored
      The DCache clean & ICache invalidation requirements for instructions
      to be data coherence are discoverable through new fields in CTR_EL0.
      The following two control bits DIC and IDC were defined for this
      purpose. No need to perform point of unification cache maintenance
      operations from software on systems where CPU caches are transparent.
      
      This patch optimize the three functions __flush_cache_user_range(),
      clean_dcache_area_pou() and invalidate_icache_range() if the hardware
      reports CTR_EL0.IDC and/or CTR_EL0.IDC. Basically it skips the two
      instructions 'DC CVAU' and 'IC IVAU', and the associated loop logic
      in order to avoid the unnecessary overhead.
      
      CTR_EL0.DIC: Instruction cache invalidation requirements for
       instruction to data coherence. The meaning of this bit[29].
        0: Instruction cache invalidation to the point of unification
           is required for instruction to data coherence.
        1: Instruction cache cleaning to the point of unification is
            not required for instruction to data coherence.
      
      CTR_EL0.IDC: Data cache clean requirements for instruction to data
       coherence. The meaning of this bit[28].
        0: Data cache clean to the point of unification is required for
           instruction to data coherence, unless CLIDR_EL1.LoC == 0b000
           or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000).
        1: Data cache clean to the point of unification is not required
           for instruction to data coherence.
      Co-authored-by: default avatarPhilip Elcan <pelcan@codeaurora.org>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarShanker Donthineni <shankerd@codeaurora.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      6ae4b6e0
    • Ard Biesheuvel's avatar
      arm64/kernel: enable A53 erratum #8434319 handling at runtime · ca79acca
      Ard Biesheuvel authored
      Omit patching of ADRP instruction at module load time if the current
      CPUs are not susceptible to the erratum.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: Drop duplicate initialisation of .def_scope field]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ca79acca
    • Ard Biesheuvel's avatar
      arm64/errata: add REVIDR handling to framework · e8002e02
      Ard Biesheuvel authored
      In some cases, core variants that are affected by a certain erratum
      also exist in versions that have the erratum fixed, and this fact is
      recorded in a dedicated bit in system register REVIDR_EL1.
      
      Since the architecture does not require that a certain bit retains
      its meaning across different variants of the same model, each such
      REVIDR bit is tightly coupled to a certain revision/variant value,
      and so we need a list of revidr_mask/midr pairs to carry this
      information.
      
      So add the struct member and the associated macros and handling to
      allow REVIDR fixes to be taken into account.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e8002e02
    • Ard Biesheuvel's avatar
      arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum #843419 · a257e025
      Ard Biesheuvel authored
      Working around Cortex-A53 erratum #843419 involves special handling of
      ADRP instructions that end up in the last two instruction slots of a
      4k page, or whose output register gets overwritten without having been
      read. (Note that the latter instruction sequence is never emitted by
      a properly functioning compiler, which is why it is disregarded by the
      handling of the same erratum in the bfd.ld linker which we rely on for
      the core kernel)
      
      Normally, this gets taken care of by the linker, which can spot such
      sequences at final link time, and insert a veneer if the ADRP ends up
      at a vulnerable offset. However, linux kernel modules are partially
      linked ELF objects, and so there is no 'final link time' other than the
      runtime loading of the module, at which time all the static relocations
      are resolved.
      
      For this reason, we have implemented the #843419 workaround for modules
      by avoiding ADRP instructions altogether, by using the large C model,
      and by passing -mpc-relative-literal-loads to recent versions of GCC
      that may emit adrp/ldr pairs to perform literal loads. However, this
      workaround forces us to keep literal data mixed with the instructions
      in the executable .text segment, and literal data may inadvertently
      turn into an exploitable speculative gadget depending on the relative
      offsets of arbitrary symbols.
      
      So let's reimplement this workaround in a way that allows us to switch
      back to the small C model, and to drop the -mpc-relative-literal-loads
      GCC switch, by patching affected ADRP instructions at runtime:
      - ADRP instructions that do not appear at 4k relative offset 0xff8 or
        0xffc are ignored
      - ADRP instructions that are within 1 MB of their target symbol are
        converted into ADR instructions
      - remaining ADRP instructions are redirected via a veneer that performs
        the load using an unaffected movn/movk sequence.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: tidied up ADRP -> ADR instruction patching.]
      [will: use ULL suffix for 64-bit immediate]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      a257e025
  6. 08 Mar, 2018 5 commits
    • Ard Biesheuvel's avatar
      arm64/kernel: kaslr: reduce module randomization range to 4 GB · f2b9ba87
      Ard Biesheuvel authored
      We currently have to rely on the GCC large code model for KASLR for
      two distinct but related reasons:
      - if we enable full randomization, modules will be loaded very far away
        from the core kernel, where they are out of range for ADRP instructions,
      - even without full randomization, the fact that the 128 MB module region
        is now no longer fully reserved for kernel modules means that there is
        a very low likelihood that the normal bottom-up allocation of other
        vmalloc regions may collide, and use up the range for other things.
      
      Large model code is suboptimal, given that each symbol reference involves
      a literal load that goes through the D-cache, reducing cache utilization.
      But more importantly, literals are not instructions but part of .text
      nonetheless, and hence mapped with executable permissions.
      
      So let's get rid of our dependency on the large model for KASLR, by:
      - reducing the full randomization range to 4 GB, thereby ensuring that
        ADRP references between modules and the kernel are always in range,
      - reduce the spillover range to 4 GB as well, so that we fallback to a
        region that is still guaranteed to be in range
      - move the randomization window of the core kernel to the middle of the
        VMALLOC space
      
      Note that KASAN always uses the module region outside of the vmalloc space,
      so keep the kernel close to that if KASAN is enabled.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f2b9ba87
    • Ard Biesheuvel's avatar
      arm64: module: don't BUG when exceeding preallocated PLT count · 5e8307b9
      Ard Biesheuvel authored
      When PLTs are emitted at relocation time, we really should not exceed
      the number that we counted when parsing the relocation tables, and so
      currently, we BUG() on this condition. However, even though this is a
      clear bug in this particular piece of code, we can easily recover by
      failing to load the module.
      
      So instead, return 0 from module_emit_plt_entry() if this condition
      occurs, which is not a valid kernel address, and can hence serve as
      a flag value that makes the relocation routine bail out.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5e8307b9
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Remove obsolete ACPI_IORT_SMMU_V3_CAVIUM_CN99XX define · 8dc12538
      Lorenzo Pieralisi authored
      To defeat ACPICA<->kernel merge order dependencies a preprocessor define
      value was introduced in the IORT compilation unit according to IORT
      revision C, IORT_SMMU_V3_CAVIUM_CN99XX, so that even if the value was
      not defined in ACPICA headers the IORT kernel layer would still be able
      to function and use it.
      
      Since commit 0c2021c0 ("ACPICA: IORT: Update SMMU models for
      revision C") finally added the define in ACPICA headers, as required by
      ACPICA IORT support, the preprocessor definition in the IORT kernel
      compilation unit has become obsolete and can be removed.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      8dc12538
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Remove temporary iort_get_id_mapping_index() ACPICA guard · 6c475063
      Lorenzo Pieralisi authored
      In IORT issue C SMMUv3 IORT nodes gained an additional field (DeviceID
      mapping index) so that the SMMUv3 can describe its MSI interrupts.
      
      Referring to it in the kernel requires ACPICA changes and in order
      to prevent kernel<->ACPICA dependencies kernel code depending on the
      SMMUv3 DeviceID mapping index field was guarded with an ACPICA version
      conditional.
      
      ACPICA changes introducing DeviceID mapping index in the IORT structs
      were integrated in the kernel with:
      
      commit 4c106aa4 ("ACPICA: iasl: Add SMMUv3 device ID mapping index
      support")
      
      so the temporary ACPICA guard has become stale and can be removed.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      6c475063
    • Jia He's avatar
      ACPI/IORT: Remove linker section for IORT entries again · c38d0852
      Jia He authored
      In commit 316ca880 ("ACPI/IORT: Remove linker section for IORT entries
      probing"), iort entries was removed in vmlinux.lds.h. But in
      commit 2fcc112a ("clocksource/drivers: Rename clksrc table to timer"),
      this line was back incorrectly.
      
      It does no harm except for adding some useless symbols, so fix it.
      Signed-off-by: default avatarJia He <jia.he@hxt-semitech.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      c38d0852
  7. 06 Mar, 2018 17 commits