1. 28 Aug, 2016 1 commit
    • Russell King's avatar
      net: smc91x: fix SMC accesses · 2fb04fdf
      Russell King authored
      Commit b70661c7 ("net: smc91x: use run-time configuration on all ARM
      machines") broke some ARM platforms through several mistakes.  Firstly,
      the access size must correspond to the following rule:
      
      (a) at least one of 16-bit or 8-bit access size must be supported
      (b) 32-bit accesses are optional, and may be enabled in addition to
          the above.
      
      Secondly, it provides no emulation of 16-bit accesses, instead blindly
      making 16-bit accesses even when the platform specifies that only 8-bit
      is supported.
      
      Reorganise smc91x.h so we can make use of the existing 16-bit access
      emulation already provided - if 16-bit accesses are supported, use
      16-bit accesses directly, otherwise if 8-bit accesses are supported,
      use the provided 16-bit access emulation.  If neither, BUG().  This
      exactly reflects the driver behaviour prior to the commit being fixed.
      
      Since the conversion incorrectly cut down the available access sizes on
      several platforms, we also need to go through every platform and fix up
      the overly-restrictive access size: Arnd assumed that if a platform can
      perform 32-bit, 16-bit and 8-bit accesses, then only a 32-bit access
      size needed to be specified - not so, all available access sizes must
      be specified.
      
      This likely fixes some performance regressions in doing this: if a
      platform does not support 8-bit accesses, 8-bit accesses have been
      emulated by performing a 16-bit read-modify-write access.
      
      Tested on the Intel Assabet/Neponset platform, which supports only 8-bit
      accesses, which was broken by the original commit.
      
      Fixes: b70661c7
      
       ("net: smc91x: use run-time configuration on all ARM machines")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Tested-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fb04fdf
  2. 24 Aug, 2016 1 commit
  3. 17 Aug, 2016 1 commit
    • Christoffer Dall's avatar
      KVM: arm/arm64: Change misleading use of is_error_pfn · 9ac71595
      Christoffer Dall authored
      
      
      When converting a gfn to a pfn, we call gfn_to_pfn_prot, which returns
      various kinds of error values.  It turns out that is_error_pfn() only
      returns true when the gfn was found in a memory slot and could somehow
      not be used, but it does not return true if the gfn does not belong to
      any memory slot.
      
      Change use to is_error_noslot_pfn() which covers both cases.
      
      Note: Since we already check for kvm_is_error_hva(hva) explicitly in the
      caller of this function while holding the kvm->srcu lock protecting the
      memory slots, this should never be a problem, but nevertheless this
      change is warranted as it shows the intention of the code.
      Reported-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      9ac71595
  4. 12 Aug, 2016 1 commit
  5. 11 Aug, 2016 1 commit
  6. 10 Aug, 2016 9 commits
  7. 09 Aug, 2016 4 commits
    • Russell King's avatar
      ARM: fix address limit restoration for undefined instructions · 87eed3c7
      Russell King authored
      
      
      During boot, sometimes the kernel will test to see if an instruction
      causes an undefined instruction exception.  Unfortunately, the exit
      path for these exceptions did not restore the address limit, which
      causes the rootfs mount code to fail.  Fix the missing address limit
      restoration.
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      87eed3c7
    • Ard Biesheuvel's avatar
      ARM: 8591/1: mm: use fully constructed struct pages for EFI pgd allocations · 61444cde
      Ard Biesheuvel authored
      The late_alloc() PTE allocation function used by create_mapping_late()
      does not call pgtable_page_ctor() on PTE pages it allocates, leaving
      the per-page spinlock uninitialized.
      
      Since generic page table manipulation code may assume that translation
      table pages that are not owned by init_mm are covered by fully
      constructed struct pages, the following crash may occur with the new
      UEFI memory attributes table code.
      
        efi: memattr: Processing EFI Memory Attributes table:
        efi: memattr:  0x0000ffa16000-0x0000ffa82fff [Runtime Code       |RUN|  |  |XP|  |  |  |   |  |  |  |  ]
        Unable to handle kernel NULL pointer dereference at virtual address 00000010
        pgd = c0204000
        [00000010] *pgd=00000000
        Internal error: Oops: 5 [#1] SMP ARM
        Modules linked in:
        CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc4-00063-g3882aa7b340b #361
        Hardware name: Generic DT based system
        task: ed858000 ti: ed842000 task.ti: ed842000
        PC is at __lock_acquire+0xa0/0x19a8
        ...
        [<c038c830>] (__lock_acquire) from [<c038e4f8>] (lock_acquire+0x6c/0x88)
        [<c038e4f8>] (lock_acquire) from [<c0c06134>] (_raw_spin_lock+0x2c/0x3c)
        [<c0c06134>] (_raw_spin_lock) from [<c0410384>] (apply_to_page_range+0xe8/0x238)
        [<c0410384>] (apply_to_page_range) from [<c1205f34>] (efi_set_mapping_permissions+0x54/0x5c)
        [<c1205f34>] (efi_set_mapping_permissions) from [<c1247474>] (efi_memattr_apply_permissions+0x2b8/0x378)
        [<c1247474>] (efi_memattr_apply_permissions) from [<c1248258>] (arm_enable_runtime_services+0x1f0/0x22c)
        [<c1248258>] (arm_enable_runtime_services) from [<c0301f0c>] (do_one_initcall+0x44/0x174)
        [<c0301f0c>] (do_one_initcall) from [<c1200d10>] (kernel_init_freeable+0x90/0x1e8)
        [<c1200d10>] (kernel_init_freeable) from [<c0bff690>] (kernel_init+0x8/0x114)
        [<c0bff690>] (kernel_init) from [<c0307ed0>] (ret_from_fork+0x14/0x24)
      
      The crash is due to the fact that the UEFI page tables are not owned by
      init_mm, but are not covered by fully constructed struct pages.
      
      Given that the UEFI subsystem is currently the only user of
      create_mapping_late(), add an unconditional call to pgtable_page_ctor() to
      late_alloc().
      
      Fixes: 9fc68b71
      
       ("ARM/efi: Apply strict permissions for UEFI Runtime Services regions")
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      61444cde
    • Nicolas Pitre's avatar
      ARM: 8590/1: sanity_check_meminfo(): avoid overflow on vmalloc_limit · b9a01989
      Nicolas Pitre authored
      
      
      To limit the amount of mapped low memory, we determine a physical address
      boundary based on the start of the vmalloc area using __pa().
      Strictly speaking, the vmalloc area location is arbitrary and does not
      necessarily corresponds to a valid physical address. For example, if
      
      	PAGE_OFFSET = 0x80000000
      	PHYS_OFFSET = 0x90000000
      	vmalloc_min = 0xf0000000
      
      then __pa(vmalloc_min) overflows and returns a wrapped 0 when phys_addr_t
      is a 32-bit type. Then the code that follows determines that the entire
      physical memory is above that boundary and no low memory gets mapped at
      all:
      
      |[...]
      |Machine model: Freescale i.MX51 NA04 Board
      |Ignoring RAM at 0x90000000-0xb0000000 (!CONFIG_HIGHMEM)
      |Consider using a HIGHMEM enabled kernel.
      
      To avoid this problem let's make vmalloc_limit a 64-bit value all the
      time and determine that boundary explicitly without using __pa().
      Reported-by: default avatarEmil Renner Berthing <kernel@esmil.dk>
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
      Tested-by: default avatarEmil Renner Berthing <kernel@esmil.dk>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b9a01989
    • Philipp Zabel's avatar
      ARM: imx6: mark GPC node as not populated after irq init to probe pm domain driver · 255c0397
      Philipp Zabel authored
      Since IRQCHIP_DECLARE now flags the GPC node as already populated, the
      GPC power domain driver is never probed unless we clear the flag again.
      
      Fixes: 15cc2ed6
      
       ("of/irq: Mark initialised interrupt controllers as populated")
      Suggested-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Cc: Jon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      255c0397
  8. 04 Aug, 2016 2 commits
  9. 03 Aug, 2016 1 commit
    • Arnd Bergmann's avatar
      Revert "ARM: aspeed: adapt defconfigs for new CONFIG_PRINTK_TIME" · 7a376ac1
      Arnd Bergmann authored
      
      
      The patch that this was preparing for made it into neither v4.7 nor
      v4.8, so we should back this out as well to avoid the opposite
      warning:
      
        arch/arm/configs/aspeed_g5_defconfig:62:warning: symbol value '1' invalid for PRINTK_TIME
        arch/arm/configs/aspeed_g4_defconfig:61:warning: symbol value '1' invalid for PRINTK_TIME
      
      Sorry for not catching this earlier.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 0ef659a3 ("ARM: aspeed: adapt defconfigs for new CONFIG_PRINTK_TIME")
      Cc: stable@vger.kernel.org # v4.7
      7a376ac1
  10. 02 Aug, 2016 7 commits
  11. 01 Aug, 2016 1 commit
  12. 30 Jul, 2016 1 commit
    • Grygorii Strashko's avatar
      ARM: OMAP2+: omap_device: fix crash on omap_device removal · 213fa10d
      Grygorii Strashko authored
      
      
      Below call chain causes system crash when OMAP device is
      removed by calling of_platform_depopulate()/device_del():
      
      device_del()
      - blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
       			     BUS_NOTIFY_DEL_DEVICE, dev);
        - _omap_device_notifier_call()
          - omap_device_delete()
            - od->pdev->archdata.od = NULL;
      	kfree(od->hwmods);
      	kfree(od);
        - bus_remove_device()
          - device_release_driver()
            - __device_release_driver()
      	- pm_runtime_get_sync()
      	   - _od_runtime_resume()
      	     - omap_hwmod_enable() <- OOPS od's delted already
      
      Backtrace:
      Unable to handle kernel NULL pointer dereference at virtual address 0000000d
      pgd = eb100000
      [0000000d] *pgd=ad6e1831, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      CPU: 1 PID: 1273 Comm: modprobe Not tainted 4.4.15-rt19-00115-ge4d3cd3-dirty #68
      Hardware name: Generic DRA74X (Flattened Device Tree)
      task: eb1ee800 ti: ec962000 task.ti: ec962000
      PC is at omap_device_enable+0x10/0x90
      LR is at _od_runtime_resume+0x10/0x24
      [...]
      [<c00299dc>] (omap_device_enable) from [<c0029a6c>] (_od_runtime_resume+0x10/0x24)
      [<c0029a6c>] (_od_runtime_resume) from [<c04ad404>] (__rpm_callback+0x20/0x34)
      [<c04ad404>] (__rpm_callback) from [<c04ad438>] (rpm_callback+0x20/0x80)
      [<c04ad438>] (rpm_callback) from [<c04aee28>] (rpm_resume+0x48c/0x964)
      [<c04aee28>] (rpm_resume) from [<c04af360>] (__pm_runtime_resume+0x60/0x88)
      [<c04af360>] (__pm_runtime_resume) from [<c04a4974>] (__device_release_driver+0x30/0x100)
      [<c04a4974>] (__device_release_driver) from [<c04a4a60>] (device_release_driver+0x1c/0x28)
      [<c04a4a60>] (device_release_driver) from [<c04a38c0>] (bus_remove_device+0xec/0x144)
      [<c04a38c0>] (bus_remove_device) from [<c04a0764>] (device_del+0x10c/0x210)
      [<c04a0764>] (device_del) from [<c04a67b0>] (platform_device_del+0x18/0x84)
      [<c04a67b0>] (platform_device_del) from [<c04a6828>] (platform_device_unregister+0xc/0x20)
      [<c04a6828>] (platform_device_unregister) from [<c05adcfc>] (of_platform_device_destroy+0x8c/0x90)
      [<c05adcfc>] (of_platform_device_destroy) from [<c04a02f0>] (device_for_each_child+0x4c/0x78)
      [<c04a02f0>] (device_for_each_child) from [<c05adc5c>] (of_platform_depopulate+0x30/0x44)
      [<c05adc5c>] (of_platform_depopulate) from [<bf123920>] (cpsw_remove+0x68/0xf4 [ti_cpsw])
      [<bf123920>] (cpsw_remove [ti_cpsw]) from [<c04a68d8>] (platform_drv_remove+0x24/0x3c)
      [<c04a68d8>] (platform_drv_remove) from [<c04a49c8>] (__device_release_driver+0x84/0x100)
      [<c04a49c8>] (__device_release_driver) from [<c04a4b20>] (driver_detach+0xac/0xb0)
      [<c04a4b20>] (driver_detach) from [<c04a3be8>] (bus_remove_driver+0x60/0xd4)
      [<c04a3be8>] (bus_remove_driver) from [<c00d9870>] (SyS_delete_module+0x184/0x20c)
      [<c00d9870>] (SyS_delete_module) from [<c0010540>] (ret_fast_syscall+0x0/0x1c)
      Code: e3500000 e92d4070 1590630c 01a06000 (e5d6300d)
      
      Hence, fix it by using BUS_NOTIFY_REMOVED_DEVICE event for OMAP device
      deletion which is sent when DD has finished processing of device
      deletion.
      
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      213fa10d
  13. 27 Jul, 2016 1 commit
  14. 26 Jul, 2016 5 commits
  15. 25 Jul, 2016 2 commits
    • Vitaly Kuznetsov's avatar
      x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op · ad5475f9
      Vitaly Kuznetsov authored
      
      
      HYPERVISOR_vcpu_op() passes Linux's idea of vCPU id as a parameter
      while Xen's idea is expected. In some cases these ideas diverge so we
      need to do remapping.
      
      Convert all callers of HYPERVISOR_vcpu_op() to use xen_vcpu_nr().
      
      Leave xen_fill_possible_map() and xen_filter_cpu_maps() intact as
      they're only being called by PV guests before perpu areas are
      initialized. While the issue could be solved by switching to
      early_percpu for xen_vcpu_id I think it's not worth it: PV guests will
      probably never get to the point where their idea of vCPU id diverges
      from Xen's.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      ad5475f9
    • Vitaly Kuznetsov's avatar
      xen: introduce xen_vcpu_id mapping · 88e957d6
      Vitaly Kuznetsov authored
      
      
      It may happen that Xen's and Linux's ideas of vCPU id diverge. In
      particular, when we crash on a secondary vCPU we may want to do kdump
      and unlike plain kexec where we do migrate_to_reboot_cpu() we try
      booting on the vCPU which crashed. This doesn't work very well for
      PVHVM guests as we have a number of hypercalls where we pass vCPU id
      as a parameter. These hypercalls either fail or do something
      unexpected.
      
      To solve the issue introduce percpu xen_vcpu_id mapping. ARM and PV
      guests get direct mapping for now. Boot CPU for PVHVM guest gets its
      id from CPUID. With secondary CPUs it is a bit more
      trickier. Currently, we initialize IPI vectors before these CPUs boot
      so we can't use CPUID. Use ACPI ids from MADT instead.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      88e957d6
  16. 22 Jul, 2016 2 commits
    • Stefan Agner's avatar
      ARM: dts: fix STMicroelectronics compatible strings · 0a6f366a
      Stefan Agner authored
      
      
      Replace the non-standard vendor prefix stm with st for
      STMicroelectronics. The drivers do not specify the vendor prefixes
      since the I2C Core strips them away from the DT provided compatible
      string. Therefore, changing existing device trees does not have any
      impact on device detection.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      0a6f366a
    • Eric Auger's avatar
      KVM: arm/arm64: Enable irqchip routing · 180ae7b1
      Eric Auger authored
      
      
      This patch adds compilation and link against irqchip.
      
      Main motivation behind using irqchip code is to enable MSI
      routing code. In the future irqchip routing may also be useful
      when targeting multiple irqchips.
      
      Routing standard callbacks now are implemented in vgic-irqfd:
      - kvm_set_routing_entry
      - kvm_set_irq
      - kvm_set_msi
      
      They only are supported with new_vgic code.
      
      Both HAVE_KVM_IRQCHIP and HAVE_KVM_IRQ_ROUTING are defined.
      KVM_CAP_IRQ_ROUTING is advertised and KVM_SET_GSI_ROUTING is allowed.
      
      So from now on IRQCHIP routing is enabled and a routing table entry
      must exist for irqfd injection to succeed for a given SPI. This patch
      builds a default flat irqchip routing table (gsi=irqchip.pin) covering
      all the VGIC SPI indexes. This routing table is overwritten by the
      first first user-space call to KVM_SET_GSI_ROUTING ioctl.
      
      MSI routing setup is not yet allowed.
      Signed-off-by: default avatarEric Auger <eric.auger@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      180ae7b1