1. 09 8月, 2016 3 次提交
    • R
      ARM: pxa: prepare pxa25x interrupts for device-tree platforms · ca5be4c6
      Robert Jarzmik 提交于
      Add the device-tree interrupts initialization function required to have
      a generic pxa25x device-tree machine.
      Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      ca5be4c6
    • R
      ARM: pxa: remove platform dma code · 1761b107
      Robert Jarzmik 提交于
      As the last pxa related driver was converted to dmaengine, it's time to
      kill the legacy dma code, which is not used anymore.
      
      This finishes the pxa dmaengine transition.
      Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      1761b107
    • R
      ARM: pxa: remove devicetree boards from pxa_defconfig · 976e509c
      Robert Jarzmik 提交于
      If both legacy and device-tree machines are mixed in the same defconfig,
      the legacy boards don't boot up anymore with gpio request deferral
      errors.
      
      This is seen when attempting to run akita, borzoi, spitz, terrier, or
      tosa in qemu with pxa_defconfig.
      
      The real reason behind is that gpio handling for pxa in its current
      state cannot be built for _both_ a devicetree machine (ie. pxa-dt.c) and
      a non devicetree machine (ie. corgi, tosa, ...).
      
      This is turn is because for devicetree a pinctrl is enforced for the
      machine, and a pinctrl driver is required. If it's not available,
      pxa_gpio_request() fails on pinctrl_request_gpio() and returns
      -EPROBE_DEFER.  It was introduced by commit f806dac5
      ("ARM: pxa: activate pinctrl for device-tree machines").
      
      Now the true chicken and egg problem is than machine files,
      ie. arch/arm/mach-pxa/xxx.c are using gpio before the drivers are
      probed, in the init_machine() function, and that's why pinctrl/gpio for
      legacy machine files is a bit difficult.
      
      As for now, to keep the compilation coverage and testing of legacy
      machines, this patch removes the 2 devicetree machines from
      pxa_defconfig.
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Tested-by: NGuenter Roeck <linux@roeck-us.net>
      976e509c
  2. 04 8月, 2016 2 次提交
  3. 03 8月, 2016 5 次提交
  4. 02 8月, 2016 1 次提交
  5. 31 7月, 2016 1 次提交
    • G
      ARM: OMAP2+: omap_device: fix crash on omap_device removal · 213fa10d
      Grygorii Strashko 提交于
      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: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      213fa10d
  6. 27 7月, 2016 5 次提交
  7. 25 7月, 2016 2 次提交
    • V
      x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op · ad5475f9
      Vitaly Kuznetsov 提交于
      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: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      ad5475f9
    • V
      xen: introduce xen_vcpu_id mapping · 88e957d6
      Vitaly Kuznetsov 提交于
      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: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      88e957d6
  8. 23 7月, 2016 2 次提交
    • S
      ARM: dts: fix STMicroelectronics compatible strings · 0a6f366a
      Stefan Agner 提交于
      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: NStefan Agner <stefan@agner.ch>
      Signed-off-by: NRob Herring <robh@kernel.org>
      0a6f366a
    • E
      KVM: arm/arm64: Enable irqchip routing · 180ae7b1
      Eric Auger 提交于
      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: NEric Auger <eric.auger@redhat.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      180ae7b1
  9. 21 7月, 2016 1 次提交
  10. 19 7月, 2016 3 次提交
  11. 18 7月, 2016 15 次提交