Skip to content
  1. Aug 27, 2016
  2. Aug 26, 2016
  3. Aug 23, 2016
  4. Aug 22, 2016
  5. Aug 09, 2016
  6. Aug 04, 2016
  7. Aug 03, 2016
  8. Aug 02, 2016
  9. 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
  10. Jul 27, 2016
  11. 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
  12. Jul 23, 2016
    • 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
  13. Jul 21, 2016