1. 07 7月, 2009 1 次提交
  2. 16 6月, 2009 1 次提交
  3. 23 5月, 2009 1 次提交
  4. 25 12月, 2008 1 次提交
  5. 11 10月, 2008 1 次提交
    • M
      [S390] xpram: per device block request queues. · 3ce66093
      Martin Schwidefsky 提交于
      The xpram driver uses a single block device queue for all of its
      devices so far. With recent kernels removing xpram module fails to
      clean up all sysfs files. The next time the xpram module is loaded
      you'll get warnings:
      
        WARNING: at fs/sysfs/dir.c:463 sysfs_add_one+0x5e/0x64()
        sysfs: duplicate filename '35:0' can not be created
        Modules linked in: xpram(+) [last unloaded: xpram]
      
      Followed by the usual WARN_ON output, followed by an error message
      from kobject_add_internal, followed by a badness in genhd. Allocating
      a block queue per device fixes this.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      3ce66093
  6. 14 7月, 2008 1 次提交
  7. 12 10月, 2007 2 次提交
  8. 10 10月, 2007 1 次提交
  9. 24 7月, 2007 1 次提交
  10. 28 9月, 2006 1 次提交
    • M
      [S390] Inline assembly cleanup. · 94c12cc7
      Martin Schwidefsky 提交于
      Major cleanup of all s390 inline assemblies. They now have a common
      coding style. Quite a few have been shortened, mainly by using register
      asm variables. Use of the EX_TABLE macro helps  as well. The atomic ops,
      bit ops and locking inlines new use the Q-constraint if a newer gcc
      is used.  That results in slightly better code.
      
      Thanks to Christian Borntraeger for proof reading the changes.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      94c12cc7
  11. 20 9月, 2006 1 次提交
  12. 08 8月, 2006 1 次提交
    • M
      [S390] xpram system device class. · 37ab46a3
      Martin Schwidefsky 提交于
      Remove system device class for xpram. It creates the directory hierarchy
      under /sys/devices/system/xpram/xpram0. The xpram0 directory is empty and
      it is always created while xpram1 and following devices are always missing,
      independent if the devices exist or not. Since the xpram devices are
      listed in /proc/partitions and /sys/block/ as slram<x> the system device
      class for xpram is meaningless.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      37ab46a3
  13. 17 7月, 2006 1 次提交
  14. 12 7月, 2006 1 次提交
  15. 27 6月, 2006 4 次提交
  16. 09 1月, 2006 1 次提交
    • C
      [PATCH] Add block_device_operations.getgeo block device method · a885c8c4
      Christoph Hellwig 提交于
      HDIO_GETGEO is implemented in most block drivers, and all of them have to
      duplicate the code to copy the structure to userspace, as well as getting
      the start sector.  This patch moves that to common code [1] and adds a
      ->getgeo method to fill out the raw kernel hd_geometry structure.  For many
      drivers this means ->ioctl can go away now.
      
      [1] the s390 block drivers are odd in this respect.  xpram sets ->start
          to 4 always which seems more than odd, and the dasd driver shifts
          the start offset around, probably because of it's non-standard
          sector size.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Cc: Jens Axboe <axboe@suse.de>
      Cc: <mike.miller@hp.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo Giarrusso <blaisorblade@yahoo.it>
      Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
      Cc: Neil Brown <neilb@cse.unsw.edu.au>
      Cc: Markus Lidel <Markus.Lidel@shadowconnect.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a885c8c4
  17. 07 1月, 2006 1 次提交
  18. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4