1. 08 7月, 2013 6 次提交
  2. 30 6月, 2013 3 次提交
    • G
      powerpc/eeh: Fix fetching bus for single-dev-PE · ea461abf
      Gavin Shan 提交于
      While running Linux as guest on top of phyp, we possiblly have
      PE that includes single PCI device. However, we didn't return
      its PCI bus correctly and it leads to failure on recovery from
      EEH errors for single-dev-PE. The patch fixes the issue.
      
      Cc: <stable@vger.kernel.org> # v3.7+
      Cc: Steve Best <sbest@us.ibm.com>
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ea461abf
    • O
      ARM: dt: Only print warning, not WARN() on bad cpu map in device tree · 8d5bc1a6
      Olof Johansson 提交于
      Due to recent changes and expecations of proper cpu bindings, there are
      now cases for many of the in-tree devicetrees where a WARN() will hit
      on boot due to badly formatted /cpus nodes.
      
      Downgrade this to a pr_warn() to be less alarmist, since it's not a
      new problem.
      
      Tested on Arndale, Cubox, Seaboard and Panda ES. Panda hits the WARN
      without this, the others do not.
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d5bc1a6
    • G
      powerpc/pci: Improve device hotplug initialization · 7846de40
      Guenter Roeck 提交于
      Commit 37f02195 (powerpc/pci: fix PCI-e devices rescan issue on powerpc
      platform) fixes a problem with interrupt and DMA initialization on hot
      plugged devices. With this commit, interrupt and DMA initialization for
      hot plugged devices is handled in the pci device enable function.
      
      This approach has a couple of drawbacks. First, it creates two code paths
      for device initialization, one for hot plugged devices and another for devices
      known during the initial PCI scan. Second, the initialization code for hot
      plugged devices is only called when the device is enabled, ie typically
      in the probe function. Also, the platform specific setup code is called each
      time pci_enable_device() is called, not only once during device discovery,
      meaning it is actually called multiple times, once for devices discovered
      during the initial scan and again each time a driver is re-loaded.
      
      The visible result is that interrupt pins are only assigned to hot plugged
      devices when the device driver is loaded. Effectively this changes the PCI
      probe API, since pci_dev->irq and the device's dma configuration will now
      only be valid after pci_enable() was called at least once. A more subtle
      change is that platform specific PCI device setup is moved from device
      discovery into the driver's probe function, more specifically into the
      pci_enable_device() call.
      
      To fix the inconsistencies, add new function pcibios_add_device.
      Call pcibios_setup_device from pcibios_setup_bus_devices if device setup
      is not complete, and from pcibios_add_device if bus setup is complete.
      
      With this change, device setup code is moved back into device initialization,
      and called exactly once for both static and hot plugged devices.
      
      [ This also fixes a regression introduced by the above patch which
        causes dev->irq to be overwritten under some cirumstances after
        MSIs have been enabled for the device which leads to crashes due
        to the MSI core "hijacking" dev->irq to store the base MSI number
        and not the LSI. --BenH
      ]
      
      Cc: Yuanquan Chen <Yuanquan.Chen@freescale.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7846de40
  3. 29 6月, 2013 2 次提交
    • D
      x86: xen: Sync the CMOS RTC as well as the Xen wallclock · 47433b8c
      David Vrabel 提交于
      Adjustments to Xen's persistent clock via update_persistent_clock()
      don't actually persist, as the Xen wallclock is a software only clock
      and modifications to it do not modify the underlying CMOS RTC.
      
      The x86_platform.set_wallclock hook is there to keep the hardware RTC
      synchronized. On a guest this is pointless.
      
      On Dom0 we can use the native implementaion which actually updates the
      hardware RTC, but we still need to keep the software emulation of RTC
      for the guests up to date. The subscription to the pvclock_notifier
      allows us to emulate this easily. The notifier is called at every tick
      and when the clock was set.
      
      Right now we only use that notifier when the clock was set, but due to
      the fact that it is called periodically from the timekeeping update
      code, we can utilize it to emulate the NTP driven drift compensation
      of update_persistant_clock() for the Xen wall (software) clock.
      
      Add a 11 minutes periodic update to the pvclock_gtod notifier callback
      to achieve that. The static variable 'next' which maintains that 11
      minutes update cycle is protected by the core code serialization so
      there is no need to add a Xen specific serialization mechanism.
      
      [ tglx: Massaged changelog and added a few comments ]
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: <xen-devel@lists.xen.org>
      Link: http://lkml.kernel.org/r/1372329348-20841-6-git-send-email-david.vrabel@citrix.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      47433b8c
    • D
      x86: xen: Sync the wallclock when the system time is set · 5584880e
      David Vrabel 提交于
      Currently the Xen wallclock is only updated every 11 minutes if NTP is
      synchronized to its clock source (using the sync_cmos_clock() work).
      If a guest is started before NTP is synchronized it may see an
      incorrect wallclock time.
      
      Use the pvclock_gtod notifier chain to receive a notification when the
      system time has changed and update the wallclock to match.
      
      This chain is called on every timer tick and we want to avoid an extra
      (expensive) hypercall on every tick.  Because dom0 has historically
      never provided a very accurate wallclock and guests do not expect one,
      we can do this simply: the wallclock is only updated if the clock was
      set.
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: <xen-devel@lists.xen.org>
      Link: http://lkml.kernel.org/r/1372329348-20841-5-git-send-email-david.vrabel@citrix.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      5584880e
  4. 28 6月, 2013 3 次提交
    • A
      mn10300: Use early_param() to parse "mem=" parameter · e3f12a53
      Akira Takeuchi 提交于
      This fixes the problem that "init=" options may not be passed to kernel
      correctly.
      
      parse_mem_cmdline() of mn10300 arch gets rid of "mem=" string from
      redboot_command_line. Then init_setup() parses the "init=" options from
      static_command_line, which is a copy of redboot_command_line, and keeps
      the pointer to the init options in execute_command variable.
      
      Since the commit 026cee00 upstream (params: <level>_initcall-like kernel
      parameters), static_command_line becomes overwritten by saved_command_line at
      do_initcall_level(). Notice that saved_command_line is a command line
      which includes "mem=" string.
      
      As a result, execute_command may point to weird string by the length of
      "mem=" parameter.
      I noticed this problem when using the command line like this:
      
          mem=128M console=ttyS0,115200 init=/bin/sh
      
      Here is the processing flow of command line parameters.
          start_kernel()
            setup_arch(&command_line)
               parse_mem_cmdline(cmdline_p)
                 * strcpy(boot_command_line, redboot_command_line);
                 * Remove "mem=xxx" from redboot_command_line.
                 * *cmdline_p = redboot_command_line;
            setup_command_line(command_line) <-- command_line is redboot_command_line
              * strcpy(saved_command_line, boot_command_line)
              * strcpy(static_command_line, command_line)
            parse_early_param()
              strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
              parse_early_options(tmp_cmdline);
                parse_args("early options", cmdline, NULL, 0, 0, 0, do_early_param);
            parse_args("Booting ..", static_command_line, ...);
              init_setup() <-- save the pointer in execute_command
            rest_init()
              kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
      
      At this point, execute_command points to "/bin/sh" string.
      
          kernel_init()
            kernel_init_freeable()
              do_basic_setup()
                do_initcalls()
                  do_initcall_level()
                    (*) strcpy(static_command_line, saved_command_line);
      
      Here, execute_command gets to point to "200" string !!
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      e3f12a53
    • A
      mn10300: Allow to pass array name to get_user() · c6dc9f0a
      Akira Takeuchi 提交于
      This fixes the following compile error:
      
      CC block/scsi_ioctl.o
      block/scsi_ioctl.c: In function 'sg_scsi_ioctl':
      block/scsi_ioctl.c:449: error: invalid initializer
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      c6dc9f0a
    • T
      powerpc/eeh: Add eeh_dev to the cache during boot · 1abd6018
      Thadeu Lima de Souza Cascardo 提交于
      commit f8f7d63f ("powerpc/eeh: Trace eeh
      device from I/O cache") broke EEH on pseries for devices that were
      present during boot and have not been hotplugged/DLPARed.
      
      eeh_check_failure will get the eeh_dev from the cache, and will get
      NULL. eeh_addr_cache_build adds the addresses to the cache, but eeh_dev
      for the giving pci_device is not set yet. Just reordering the call to
      eeh_addr_cache_insert_dev works fine. The ordering is similar to the one
      in eeh_add_device_late.
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Acked-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1abd6018
  5. 25 6月, 2013 1 次提交
  6. 24 6月, 2013 6 次提交
  7. 22 6月, 2013 2 次提交
    • A
      aout32 coredump compat fix · 945fb136
      Al Viro 提交于
      dump_seek() does SEEK_CUR, not SEEK_SET; native binfmt_aout
      handles it correctly (seeks by PAGE_SIZE - sizeof(struct user),
      getting the current position to PAGE_SIZE), compat one seeks
      by PAGE_SIZE and ends up at PAGE_SIZE + already written...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      945fb136
    • S
      sched_clock: Add temporary asm/sched_clock.h · 629a6a2b
      Stephen Boyd 提交于
      Some new users of the ARM sched_clock framework are going through
      the arm-soc tree. Before 38ff87f7 (sched_clock: Make ARM's
      sched_clock generic for all architectures, 2013-06-01) the header
      file was in asm, but now it's in linux. One solution would be to
      do an evil merge of the arm-soc tree and fix up the asm users,
      but it's easier to add a temporary asm header that we can remove
      along with the few stragglers after the merge window is over.
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      629a6a2b
  8. 21 6月, 2013 1 次提交
  9. 20 6月, 2013 7 次提交
  10. 19 6月, 2013 9 次提交