1. 16 1月, 2013 3 次提交
  2. 01 12月, 2012 1 次提交
    • J
      s390/pci: PCI hotplug support via SCLP · 7441b062
      Jan Glauber 提交于
      Add SCLP PCI configure/deconfigure and implement a PCI hotplug
      controller (s390_pci_hpc). The hotplug controller creates a slot
      for every PCI function in stand-by or configured state. The PCI
      functions are named after the PCI function ID (fid). By writing to
      the power attribute in /sys/bus/pci/slots/<fid>/power the PCI function
      is moved to stand-by or configured state. If moved to the configured
      state the device is automatically scanned by the s390 PCI layer.
      Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      7441b062
  3. 23 11月, 2012 1 次提交
  4. 16 11月, 2012 1 次提交
    • J
      TTY: call tty_port_destroy in the rest of drivers · 191c5f10
      Jiri Slaby 提交于
      After commit "TTY: move tty buffers to tty_port", the tty buffers are
      not freed in some drivers. This is because tty_port_destructor is not
      called whenever a tty_port is freed. This was an assumption I counted
      with but was unfortunately untrue. So fix the drivers to fulfil this
      assumption.
      
      To be sure, the TTY buffers (and later some stuff) are gone along with
      the tty_port, we have to call tty_port_destroy at tear-down places.
      This is mostly where the structure containing a tty_port is freed.
      This patch does exactly that -- put tty_port_destroy at those places.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      191c5f10
  5. 15 11月, 2012 1 次提交
    • H
      s390/3215: fix tty close handling · ae289dc1
      Heiko Carstens 提交于
      The 3215 console always has the RAW3215_FIXED flag set, which causes
      raw3215_shutdown() not to wait for outstanding I/O requests if an attached
      tty gets closed.
      The flag however can be simply removed, so we can guarantee that all requests
      belonging to the tty have been processed when the tty is closed.
      
      However the tasklet that belongs to the 3215 device may be scheduled even if
      there is no tty attached anymore, since we have a race between console and tty
      processing.
      Thefore unconditional tty_wakekup() in raw3215_wakeup() can cause the following
      NULL pointer dereference:
      
      3.465368 Unable to handle kernel pointer dereference at virtual kernel address (null)
      3.465448 Oops: 0004 #1 SMP
      3.465454 Modules linked in:
      3.465459 CPU: 1 Not tainted 3.6.0 #1
      3.465462 Process swapper/1 (pid: 0, task: 000000003ffa4428, ksp: 000000003ffb7ce0)
      3.465466 Krnl PSW : 0404100180000000 0000000000162f86 (__wake_up+0x46/0xb8)
      3.465480            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
               Krnl GPRS: fffffffffffffffe 0000000000000000 0000000000000160 0000000000000001
      3.465492            0000000000000001 0000000000000004 0000000000000004 000000000096b490
      3.465499            0000000000000001 0000000000000100 0000000000000001 0000000000000001
      3.465506            070000003fc87d60 0000000000000160 000000003fc87d68 000000003fc87d00
      3.465526 Krnl Code: 0000000000162f76: e3c0f0a80004      lg      %r12,168(%r15)
                          0000000000162f7c: 58000370          l       %r0,880
                         #0000000000162f80: c007ffffffff00    xilf    %r0,4294967295
                         >0000000000162f86: ba102000          cs      %r1,%r0,0(%r2)
                          0000000000162f8a: 1211              ltr     %r1,%r1
                          0000000000162f8c: a774002f          brc     7,162fea
                          0000000000162f90: b904002d          lgr     %r2,%r13
                          0000000000162f94: b904003a          lgr     %r3,%r10
      3.465597 Call Trace:
      3.465599 (<0400000000000000> 0x400000000000000)
      3.465602  <000000000048c77e> raw3215_wakeup+0x2e/0x40
      3.465607  <0000000000134d66> tasklet_action+0x96/0x168
      3.465612  <000000000013423c> __do_softirq+0xd8/0x21c
      3.465615  <0000000000134678> irq_exit+0xa8/0xac
      3.465617  <000000000046c232> do_IRQ+0x182/0x248
      3.465621  <00000000005c8296> io_return+0x0/0x8
      3.465625  <00000000005c7cac> vtime_stop_cpu+0x4c/0xb8
      3.465629 (<0000000000194e06> tick_nohz_idle_enter+0x4e/0x74)
      3.465633  <0000000000104760> cpu_idle+0x170/0x184
      3.465636  <00000000005b5182> smp_start_secondary+0xd6/0xe0
      3.465641  <00000000005c86be> restart_int_handler+0x56/0x6c
      3.465643  <0000000000000000> 0x0
      3.465645 Last Breaking-Event-Address:
      3.465647  <0000000000403136> tty_wakeup+0x46/0x98
      3.465652
      3.465654 Kernel panic - not syncing: Fatal exception in interrupt
      01: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 0010F63C
      
      The easiest solution is simply to check if tty is NULL in the tasklet.
      If it is NULL nothing is to do (no tty attached), otherwise tty_wakeup()
      can be called, since we hold a reference to the tty.
      This is not nice... but it is a small patch and it works.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      ae289dc1
  6. 26 9月, 2012 5 次提交
  7. 14 8月, 2012 5 次提交
  8. 11 8月, 2012 1 次提交
  9. 08 8月, 2012 1 次提交
  10. 20 7月, 2012 1 次提交
    • H
      s390/comments: unify copyright messages and remove file names · a53c8fab
      Heiko Carstens 提交于
      Remove the file name from the comment at top of many files. In most
      cases the file name was wrong anyway, so it's rather pointless.
      
      Also unify the IBM copyright statement. We did have a lot of sightly
      different statements and wanted to change them one after another
      whenever a file gets touched. However that never happened. Instead
      people start to take the old/"wrong" statements to use as a template
      for new files.
      So unify all of them in one go.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      a53c8fab
  11. 14 6月, 2012 1 次提交
  12. 05 6月, 2012 2 次提交
  13. 24 5月, 2012 1 次提交
  14. 18 5月, 2012 1 次提交
  15. 16 5月, 2012 2 次提交
  16. 18 4月, 2012 1 次提交
  17. 14 4月, 2012 2 次提交
  18. 11 4月, 2012 1 次提交
  19. 10 4月, 2012 8 次提交
  20. 29 3月, 2012 1 次提交