Skip to content
  1. Sep 14, 2016
  2. Aug 29, 2016
    • Arnd Bergmann's avatar
      ARM: dts: mvebu: fix reference to a390 spi controller · a305cc2f
      Arnd Bergmann authored
      
      
      The SPI controller in the arch/arm/boot/dts/armada-39x.dtsi file has moved
      to a different location in the hierarchy, which breaks the overrides
      in the board specific file:
      
      Warning (reg_format): "reg" property in /soc/internal-regs/spi@10680/spi-flash@1 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
      Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/internal-regs/spi@10680/spi-flash@1
      
      This changes the board to reference the spi controller by its label
      (which has not changed) rather than the full path.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 0160a4b6 ("ARM: dts: mvebu: A37x/XP/38x/39x: Move SPI controller nodes into 'soc' node")
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      a305cc2f
  3. Aug 26, 2016
  4. Aug 08, 2016
  5. Aug 04, 2016
  6. Aug 03, 2016
  7. Aug 02, 2016
  8. Jul 31, 2016
    • 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
  9. Jul 27, 2016
  10. Jul 25, 2016
    • 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
  11. Jul 23, 2016