1. 17 6月, 2014 13 次提交
    • R
      ARM: use menuconfig for sub-arch menus · 21278aea
      Rob Herring 提交于
      The System Type menu is getting quite long with platforms and is
      inconsistent in handling of sub-arch specific options. Tidy up the menu
      by making platform options a menuconfig entry containing any platform
      specific config items.
      
      [arnd: change OMAP part according to suggestion from
       Tony Lindgren <tony@atomide.com>]
      Signed-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      21278aea
    • S
      ARM: multi_v7_defconfig: re-enable SDHCI drivers · 216e9d3e
      Stephen Warren 提交于
      Following 5d01b768 "mmc: simplify SDHCI Kconfig dependencies",
      SDHCI drivers that use MMC_SDHCI_PLTFM no longer select it, but
      instead depend on it. This means that multi_v7_defconfig no longer
      selects it, and hence many SDHCI drivers are no longer enabled.
      Explicitly enable MMC_SDHCI_PLTFM to solve this.
      
      Fixes: 5d01b768 ("mmc: simplify SDHCI Kconfig dependencies")
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Tested-by: NMatt Porter <mporter@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      216e9d3e
    • S
      ARM: EXYNOS: Fix compilation warning · 3eb93646
      Sachin Kamat 提交于
      of_get_flat_dt_prop return type is now const.
      Fixes the following compilation warning introduced by commit 9d0c4dfe
      ("of/fdt: update of_get_flat_dt_prop in prep for libfdt")
      
      arch/arm/mach-exynos/exynos.c:259:6: warning:
      assignment discards ‘const’ qualifier from pointer target type [enabled by default]
      Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
      Reviewed-by: NTushar Behera <tushar.behera@linaro.org>
      Cc: Rob Herring <robh@kernel.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      3eb93646
    • O
      ARM: exynos: move sysram info to exynos.c · 1754c42e
      Olof Johansson 提交于
      This solves a problem with building with CONFIG_SMP=n due to missing
      sysram_base_addr (or sysram_ns_base_addr) variables.
      
      The new setup method is more awkward than I'd like for it to be, but
      it can't be done in init_early() since ioremap is not yet available,
      but it needs to happen before SMP.
      Reported-by: NRussell King <linux@arm.linux.org.uk>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Reviewed-by: NTomasz Figa <t.figa@samsung.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      1754c42e
    • E
      ARM: dts: Specify the NAND ECC scheme explicitly on Armada 385 DB board · 1ad58443
      Ezequiel Garcia 提交于
      The factory bootloader on A385-DB boards expect the ECC strength to be
      4 bits over 512 bytes. Hence, we need to specify this in the devicetree,
      to prevent the kernel from assuming any different ECC scheme.
      Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Link: https://lkml.kernel.org/r/1400941030-2123-3-git-send-email-ezequiel.garcia@free-electrons.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>
      1ad58443
    • E
      ARM: dts: Specify the NAND ECC scheme explicitly on Armada 375 DB board · 3364ee57
      Ezequiel Garcia 提交于
      The factory bootloader on A375-DB boards expect the ECC strength to be
      4 bits over 512 bytes. Hence, we need to specify this in the devicetree,
      to prevent the kernel from assuming any different ECC scheme.
      Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Link: https://lkml.kernel.org/r/1400941030-2123-2-git-send-email-ezequiel.garcia@free-electrons.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>
      3364ee57
    • R
      ARM: exynos: cleanup kconfig option display · e509b289
      Rob Herring 提交于
      The addition of Exynos to multi-platform configs creates a mess of config
      options with options appearing before the Exynos config option. This is
      due to arch/arm/plat-samsung/Kconfig being included out of order with the
      other Samsung platform kconfig files. Reorder the kconfig files and move
      all the options into a sub-menu. Some of the options are dead, so remove
      those as well.
      Signed-off-by: NRob Herring <robh@kernel.org>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: linux-samsung-soc@vger.kernel.org
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      e509b289
    • S
      ARM: Remove ARCH_HAS_CPUFREQ config option · 19682f72
      Stephen Boyd 提交于
      This config exists entirely to hide the cpufreq menu from the
      kernel configuration unless a platform has selected it. Nothing
      is actually built if this config is 'Y' and it just leads to more
      patches that add a select under a platform Kconfig so that some
      other CPUfreq option can be chosen. Let's remove the option so
      that we can always enable CPUfreq drivers on ARM platforms.
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      19682f72
    • L
      ARM: integrator: fix section mismatch problem · e1318391
      Linus Walleij 提交于
      This addresses a section mismatch problem in the IM-PD1
      driver in the Integrator/AP.
      
      The IM-PD1 contains a VIC interrupt controller and therefore
      the driver calls vic_init_cascaded() which is marked __init as
      irqchips are simply not hot-pluggable and specifically the VIC
      is assumed to initiate only on boot.
      
      However the module driver model of the Integrator LM bus
      assumes that logic tile drivers can be probed at runtime. This
      is not really the case for IM-PD1: these tiles are detected at
      boot and they cannot be plugged into a running system. Before
      this patch it is of course possible to modprobe them later.
      
      By first forcing the IM-PD1 to bool we make sure this driver
      gets compiled into the kernel, and we know it will be probed
      only at boot time when the tiles are detected, so we can tag
      its probe function __init_refok as we know it won't be called
      after boot now, and the section mismatch problem goes away.
      
      As a side effect, sysfs binding from userspace becomes
      impossible, so we tag the driver to suppress the bind/unbind
      sysfs attributes.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      e1318391
    • J
      ARM: mvebu: DT: fix OpenBlocks AX3-4 RAM size · e47043ae
      Jason Cooper 提交于
      The OpenBlocks AX3-4 has a non-DT bootloader.  It also comes with 1GB of
      soldered on RAM, and a DIMM slot for expansion.
      
      Unfortunately, atags_to_fdt() doesn't work in big-endian mode, so we see
      the following failure when attempting to boot a big-endian kernel:
      
        686 slab pages
        17 pages shared
        0 pages swap cached
        [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
        Kernel panic - not syncing: Out of memory and no killable processes...
      
        CPU: 1 PID: 351 Comm: kworker/u4:0 Not tainted 3.15.0-rc8-next-20140603 #1
        [<c0215a54>] (unwind_backtrace) from [<c021160c>] (show_stack+0x10/0x14)
        [<c021160c>] (show_stack) from [<c0802500>] (dump_stack+0x78/0x94)
        [<c0802500>] (dump_stack) from [<c0800068>] (panic+0x90/0x21c)
        [<c0800068>] (panic) from [<c02b5704>] (out_of_memory+0x320/0x340)
        [<c02b5704>] (out_of_memory) from [<c02b93a0>] (__alloc_pages_nodemask+0x874/0x930)
        [<c02b93a0>] (__alloc_pages_nodemask) from [<c02d446c>] (handle_mm_fault+0x744/0x96c)
        [<c02d446c>] (handle_mm_fault) from [<c02cf250>] (__get_user_pages+0xd0/0x4c0)
        [<c02cf250>] (__get_user_pages) from [<c02f3598>] (get_arg_page+0x54/0xbc)
        [<c02f3598>] (get_arg_page) from [<c02f3878>] (copy_strings+0x278/0x29c)
        [<c02f3878>] (copy_strings) from [<c02f38bc>] (copy_strings_kernel+0x20/0x28)
        [<c02f38bc>] (copy_strings_kernel) from [<c02f4f1c>] (do_execve+0x3a8/0x4c8)
        [<c02f4f1c>] (do_execve) from [<c025ac10>] (____call_usermodehelper+0x15c/0x194)
        [<c025ac10>] (____call_usermodehelper) from [<c020e9b8>] (ret_from_fork+0x14/0x3c)
        CPU0: stopping
        CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc8-next-20140603 #1
        [<c0215a54>] (unwind_backtrace) from [<c021160c>] (show_stack+0x10/0x14)
        [<c021160c>] (show_stack) from [<c0802500>] (dump_stack+0x78/0x94)
        [<c0802500>] (dump_stack) from [<c021429c>] (handle_IPI+0x138/0x174)
        [<c021429c>] (handle_IPI) from [<c02087f0>] (armada_370_xp_handle_irq+0xb0/0xcc)
        [<c02087f0>] (armada_370_xp_handle_irq) from [<c0212100>] (__irq_svc+0x40/0x50)
        Exception stack(0xc0b6bf68 to 0xc0b6bfb0)
        bf60:                   e9fad598 00000000 00f509a3 00000000 c0b6a000 c0b724c4
        bf80: c0b72458 c0b6a000 00000000 00000000 c0b66da0 c0b6a000 00000000 c0b6bfb0
        bfa0: c027bb94 c027bb24 60000313 ffffffff
        [<c0212100>] (__irq_svc) from [<c027bb24>] (cpu_startup_entry+0x54/0x214)
        [<c027bb24>] (cpu_startup_entry) from [<c0ac5b30>] (start_kernel+0x318/0x37c)
        [<c0ac5b30>] (start_kernel) from [<00208078>] (0x208078)
        ---[ end Kernel panic - not syncing: Out of memory and no killable processes...
      
      A similar failure will also occur if ARM_ATAG_DTB_COMPAT isn't selected.
      
      Fix this by setting a sane default (1 GB) in the dts file.
      Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      Tested-by: NKevin Hilman <khilman@linaro.org>
      Cc: <stable@vger.kernel.org> #v3.13+
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      e47043ae
    • A
      ARM: samsung: make SAMSUNG_DMADEV optional · 27873b05
      Arnd Bergmann 提交于
      The only remaining driver using the samsung dmadev code is the broken
      samsung-ac97 sound driver. However, as found by Russell's autobuilder,
      the elaborate dependency chains around it cause problems with
      circular dependencies.
      
      This is an attempt to simplify those dependencies by making the
      SAMSUNG_DMADEV option user-selectable. I also try to keep the
      default settings for all related options unchanged, so we don't
      introduce any regressions against earlier testing on linux-next.
      
      In particular, all s3c64xx and s5p* platforms keep selecting the
      pl330 and pl08x drivers they require, but the select statement
      is now moved towards the main platform option, and it remains
      optional by unselecting CONFIG_DMADEVICES.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      27873b05
    • A
      ARM: keystone requires ARM_PATCH_PHYS_VIRT · 13ee8955
      Arnd Bergmann 提交于
      The dynamic relocation that the keystone platform performs
      only works if we can pick the phys offset at boot time. It's
      possible that there is another solution for this, but this
      is the easiest workaround. Kernels with ARM_PATCH_PHYS_VIRT
      are not portable across platforms, and I see no reason why
      anyone would run a kernel without ARM_PATCH_PHYS_VIRT on
      keystone.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      13ee8955
    • A
      ARM: omap2: fix am43xx dependency on l2x0 cache · 2ad501cc
      Arnd Bergmann 提交于
      Commit d941f86f ("ARM: l2c: AM43x: add L2 cache support") enabled
      the L2 cache support for the am43xx SoC, but caused a build regression
      when the driver for that cache controller is disabled:
      
      arch/arm/mach-omap2/built-in.o: In function `am43xx_init_early':
      :(.init.text+0xb20): undefined reference to `omap_l2_cache_init'
      
      This did not happen for OMAP4, which has the same call, but enables
      the l2x0 driver unconditionally. We could do the same thing for
      am43xx, but it seems better to allow turning it off and make the
      code work in either case.
      
      This adds an inline wrapper for omap_l2_cache_init for the disabled
      case, and removes the 'select' from OMAP4 so it becomes a user
      visible option.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: linux-omap@vger.kernel.org
      2ad501cc
  2. 11 6月, 2014 2 次提交
  3. 09 6月, 2014 1 次提交
  4. 08 6月, 2014 3 次提交
  5. 07 6月, 2014 13 次提交
  6. 06 6月, 2014 2 次提交
    • M
      powerpc/mm: Check paca psize is up to date for huge mappings · 09567e7f
      Michael Ellerman 提交于
      We have a bug in our hugepage handling which exhibits as an infinite
      loop of hash faults. If the fault is being taken in the kernel it will
      typically trigger the softlockup detector, or the RCU stall detector.
      
      The bug is as follows:
      
       1. mmap(0xa0000000, ..., MAP_FIXED | MAP_HUGE_TLB | MAP_ANONYMOUS ..)
       2. Slice code converts the slice psize to 16M.
       3. The code on lines 539-540 of slice.c in slice_get_unmapped_area()
          synchronises the mm->context with the paca->context. So the paca slice
          mask is updated to include the 16M slice.
       3. Either:
          * mmap() fails because there are no huge pages available.
          * mmap() succeeds and the mapping is then munmapped.
          In both cases the slice psize remains at 16M in both the paca & mm.
       4. mmap(0xa0000000, ..., MAP_FIXED | MAP_ANONYMOUS ..)
       5. The slice psize is converted back to 64K. Because of the check on line 539
          of slice.c we DO NOT update the paca->context. The paca slice mask is now
          out of sync with the mm slice mask.
       6. User/kernel accesses 0xa0000000.
       7. The SLB miss handler slb_allocate_realmode() **uses the paca slice mask**
          to create an SLB entry and inserts it in the SLB.
      18. With the 16M SLB entry in place the hardware does a hash lookup, no entry
          is found so a data access exception is generated.
      19. The data access handler calls do_page_fault() -> handle_mm_fault().
      10. __handle_mm_fault() creates a THP mapping with do_huge_pmd_anonymous_page().
      11. The hardware retries the access, there is still nothing in the hash table
          so once again a data access exception is generated.
      12. hash_page() calls into __hash_page_thp() and inserts a mapping in the
          hash. Although the THP mapping maps 16M the hashing is done using 64K
          as the segment page size.
      13. hash_page() returns immediately after calling __hash_page_thp(), skipping
          over the code at line 1125. Resulting in the mismatch between the
          paca->context and mm->context not being detected.
      14. The hardware retries the access, the hash it generates using the 16M
          SLB entry does NOT match the hash we inserted.
      15. We take another data access and go into __hash_page_thp().
      16. We see a valid entry in the hpte_slot_array and so we call updatepp()
          which succeeds.
      17. Goto 14.
      
      We could fix this in two ways. The first would be to remove or modify
      the check on line 539 of slice.c.
      
      The second option is to cause the check of paca psize in hash_page() on
      line 1125 to also be done for THP pages.
      
      We prefer the latter, because the check & update of the paca psize is
      not done until we know it's necessary. It's also done only on the
      current cpu, so we don't need to IPI all other cpus.
      
      Without further rearranging the code, the simplest fix is to pull out
      the code that checks paca psize and call it in two places. Firstly for
      THP/hugetlb, and secondly for other mappings as before.
      
      Thanks to Dave Jones for trinity, which originally found this bug.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: stable@vger.kernel.org [v3.11+]
      09567e7f
    • S
      ARM: keystone: Drop use of meminfo since its not available anymore · bbea06f3
      Santosh Shilimkar 提交于
      Laura's series removed the meminfo structure and its no longer available.
      Update keystone code to remove the usage of it.
      Reported-by: NRussell King - ARM Linux <linux@arm.linux.org.uk>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      bbea06f3
  7. 05 6月, 2014 6 次提交
    • I
      x86/smpboot: Initialize secondary CPU only if master CPU will wait for it · 3e1a878b
      Igor Mammedov 提交于
      Hang is observed on virtual machines during CPU hotplug,
      especially in big guests with many CPUs. (It reproducible
      more often if host is over-committed).
      
      It happens because master CPU gives up waiting on
      secondary CPU and allows it to run wild. As result
      AP causes locking or crashing system. For example
      as described here:
      
         https://lkml.org/lkml/2014/3/6/257
      
      If master CPU have sent STARTUP IPI successfully,
      and AP signalled to master CPU that it's ready
      to start initialization, make master CPU wait
      indefinitely till AP is onlined.
      To ensure that AP won't ever run wild, make it
      wait at early startup till master CPU confirms its
      intention to wait for AP. If AP doesn't respond in 10
      seconds, the master CPU will timeout and cancel
      AP onlining.
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1401975765-22328-4-git-send-email-imammedo@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3e1a878b
    • I
      x86/smpboot: Log error on secondary CPU wakeup failure at ERR level · feef1e8e
      Igor Mammedov 提交于
      If system is running without debug level logging,
      it will not log error if do_boot_cpu() failed to
      wakeup AP. It may lead to silent AP bringup
      failures at boot time.
      Change message level to KERN_ERR to make error
      visible to user as it's done on other architectures.
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1401975765-22328-3-git-send-email-imammedo@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      feef1e8e
    • I
      x86: Fix list/memory corruption on CPU hotplug · 89f898c1
      Igor Mammedov 提交于
      currently if AP wake up is failed, master CPU marks AP as not
      present in do_boot_cpu() by calling set_cpu_present(cpu, false).
      That leads to following list corruption on the next physical CPU
      hotplug:
      
      [  418.107336] WARNING: CPU: 1 PID: 45 at lib/list_debug.c:33 __list_add+0xbe/0xd0()
      [  418.115268] list_add corruption. prev->next should be next (ffff88003dc57600), but was ffff88003e20c3a0. (prev=ffff88003e20c3a0).
      [  418.123693] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT ipt_REJECT cfg80211 xt_conntrack rfkill ee
      [  418.138979] CPU: 1 PID: 45 Comm: kworker/u10:1 Not tainted 3.14.0-rc6+ #387
      [  418.149989] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
      [  418.165750] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
      [  418.166433]  0000000000000021 ffff880038ca7988 ffffffff8159b22d 0000000000000021
      [  418.176460]  ffff880038ca79d8 ffff880038ca79c8 ffffffff8106942c ffff880038ca79e8
      [  418.177453]  ffff88003e20c3a0 ffff88003dc57600 ffff88003e20c3a0 00000000ffffffea
      [  418.178445] Call Trace:
      [  418.185811]  [<ffffffff8159b22d>] dump_stack+0x49/0x5c
      [  418.186440]  [<ffffffff8106942c>] warn_slowpath_common+0x8c/0xc0
      [  418.187192]  [<ffffffff81069516>] warn_slowpath_fmt+0x46/0x50
      [  418.191231]  [<ffffffff8136ef51>] ? acpi_ns_get_node+0xb7/0xc7
      [  418.193889]  [<ffffffff812f796e>] __list_add+0xbe/0xd0
      [  418.196649]  [<ffffffff812e2aa9>] kobject_add_internal+0x79/0x200
      [  418.208610]  [<ffffffff812e2e18>] kobject_add_varg+0x38/0x60
      [  418.213831]  [<ffffffff812e2ef4>] kobject_add+0x44/0x70
      [  418.229961]  [<ffffffff813e2c60>] device_add+0xd0/0x550
      [  418.234991]  [<ffffffff813f0e95>] ? pm_runtime_init+0xe5/0xf0
      [  418.250226]  [<ffffffff813e32be>] device_register+0x1e/0x30
      [  418.255296]  [<ffffffff813e82a3>] register_cpu+0xe3/0x130
      [  418.266539]  [<ffffffff81592be5>] arch_register_cpu+0x65/0x150
      [  418.285845]  [<ffffffff81355c0d>] acpi_processor_hotadd_init+0x5a/0x9b
      ...
      Which is caused by the fact that generic_processor_info() allocates
      logical CPU id by calling:
      
       cpu = cpumask_next_zero(-1, cpu_present_mask);
      
      which returns id of previously failed to wake up CPU, since its
      bit is cleared by do_boot_cpu() and as result register_cpu()
      tries to register another CPU with the same id as already
      present but failed to be onlined CPU.
      
      Taking in account that AP will not do anything if master CPU
      failed to wake it up, there is no reason to mark that AP as not
      present and break next cpu hotplug attempts. As a side effect of
      not marking AP as not present, user would be allowed to online
      it again later.
      
      Also fix memory corruption in acpi_unmap_lsapic()
      
      if during CPU hotplug master CPU failed to wake up AP
      it set percpu x86_cpu_to_apicid to BAD_APICID=0xFFFF for AP.
      
      However following attempt to unplug that CPU will lead to
      out of bound write access to __apicid_to_node[] which is
      32768 items long on x86_64 kernel.
      
      So with above fix of cpu_present_mask make sure that a present
      CPU has a valid APIC ID by not setting x86_cpu_to_apicid
      to BAD_APICID in do_boot_cpu() on failure and allow
      acpi_processor_remove()->acpi_unmap_lsapic() cleanly remove CPU.
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1401975765-22328-2-git-send-email-imammedo@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      89f898c1
    • A
      microblaze: Fix typo in head.S s/substract/subtract/ · 225fba21
      Antonio Ospite 提交于
      Signed-off-by: NAntonio Ospite <ao2@ao2.it>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
      Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      225fba21
    • V
      powerpc/powernv: Pass buffer size to OPAL validate flash call · 8b8f7bf4
      Vasant Hegde 提交于
      We pass actual buffer size to opal_validate_flash() OPAL API call
      and in return it contains output buffer size.
      
      Commit cc146d1d (Fix little endian issues) missed to set the size
      param before making OPAL call. So firmware image validation fails.
      
      This patch sets size variable before making OPAL call.
      Signed-off-by: NVasant Hegde <hegdevasant@linux.vnet.ibm.com>
      Tested-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8b8f7bf4
    • A
      powerpc/pseries: hcall functions are exported to modules, need _GLOBAL_TOC() · c1931e21
      Anton Blanchard 提交于
      The hcall macros may call out to c code for tracing, so we need
      to set up a valid r2. This fixes an oops found when testing
      ibmvscsi as a module.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c1931e21