1. 07 7月, 2012 3 次提交
  2. 06 7月, 2012 4 次提交
    • H
      mtd: nandsim: don't open code a do_div helper · 596fd462
      Herton Ronaldo Krzesinski 提交于
      We don't need to open code the divide function, just use div_u64 that
      already exists and do the same job. While this is a straightforward
      clean up, there is more to that, the real motivation for this.
      
      While building on a cross compiling environment in armel, using gcc
      4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5), I was getting the following build
      error:
      
      ERROR: "__aeabi_uldivmod" [drivers/mtd/nand/nandsim.ko] undefined!
      
      After investigating with objdump and hand built assembly version
      generated with the compiler, I narrowed __aeabi_uldivmod as being
      generated from the divide function. When nandsim.c is built with
      -fno-inline-functions-called-once, that happens when
      CONFIG_DEBUG_SECTION_MISMATCH is enabled, the do_div optimization in
      arch/arm/include/asm/div64.h doesn't work as expected with the open
      coded divide function: even if the do_div we are using doesn't have a
      constant divisor, the compiler still includes the else parts of the
      optimized do_div macro, and translates the divisions there to use
      __aeabi_uldivmod, instead of only calling __do_div_asm -> __do_div64 and
      optimizing/removing everything else out.
      
      So to reproduce, gcc 4.6 plus CONFIG_DEBUG_SECTION_MISMATCH=y and
      CONFIG_MTD_NAND_NANDSIM=m should do it, building on armel.
      
      After this change, the compiler does the intended thing even with
      -fno-inline-functions-called-once, and optimizes out as expected the
      constant handling in the optimized do_div on arm. As this also avoids a
      build issue, I'm marking for Stable, as I think is applicable for this
      case.
      Signed-off-by: NHerton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
      Cc: stable@vger.kernel.org
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      596fd462
    • S
      mtd: gpmi-nand: fix read page when reading to vmalloced area · 6023813a
      Sascha Hauer 提交于
      The gpmi-nand driver uses virt_addr_valid() to check whether a buffer
      is suitable for dma. If it's not, a driver allocated buffer is used
      instead. Then after a page read the driver allocated buffer must be
      copied to the user supplied buffer. This does not happen since commit
      7725cc85.
      
      This patch fixes the issue. The bug is encountered with UBI which uses a
      vmalloced buffer for the volume table.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Tested-by: snijsure@grid-net.com
      Acked-by: NHuang Shijie <b32955@freescale.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      6023813a
    • S
      mtd: mxc_nand: use 32bit copy functions · 096bcc23
      Sascha Hauer 提交于
      The following commit changes the function used to copy from/to
      the hardware buffer to memcpy_[from|to]io. This does not work
      since the hardware cannot handle the byte accesses used by these
      functions. Instead of reverting this patch introduce 32bit
      correspondents of these functions.
      
      | commit 5775ba36ea9c760c2d7e697dac04f2f7fc95aa62
      | Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      | Date:   Tue Apr 24 10:05:22 2012 +0200
      |
      |    mtd: mxc_nand: fix several sparse warnings about incorrect address space
      |
      |     Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      |     Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      096bcc23
    • D
      mtd: cafe_nand: fix an & vs | mistake · 48f8b641
      Dan Carpenter 提交于
      The intent here was clearly to set result to true if the 0x40000000 flag
      was set.  But instead there was a | vs & typo and we always set result
      to true.
      
      Artem: check the spec at
      wiki.laptop.org/images/5/5c/88ALP01_Datasheet_July_2007.pdf
      and this fix looks correct.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      48f8b641
  3. 09 6月, 2012 2 次提交
    • S
      mtd: nand: initialize bitflip_threshold prior to BBT scanning · ea3b2ea2
      Shmulik Ladkani 提交于
      As of edbc4540 [mtd: driver _read() returns max_bitflips; mtd_read()
      returns -EUCLEAN], 'mtd->bitflip_threshold' must be set for mtd devices
      having ECC, prior any 'mtd_read()' call.
      Otherwise, 'mtd_read()' will falsely return -EUCLEAN.
      
      Normally, 'mtd->bitflip_threshold' is initialized when the MTD is added.
      
      However, this is too late for NAND MTDs, as 'scan_bbt()' is invoked
      prior the existing initialization of 'mtd->bitflip_threshold'.
      
      This is a problem since 'scan_bbt()' calls 'mtd_read()', in the case
      of a flash-based bad block table.
      It resulted in a falsely reported bitflips indication during BBT read,
      which lead to constant scrubbing of the flash BBT blocks.
      
      Initialize 'mtd->bitflip_threshold' to its default value (if not already
      set by the driver), prior to invocation of 'scan_bbt()'.
      Reported-by: NSascha Hauer <s.hauer@pengutronix.de>
      Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      ea3b2ea2
    • L
      Revert "drm/i915/crt: Do not rely upon the HPD presence pin" · 8f53369b
      Linus Torvalds 提交于
      This reverts commit 9e612a00.
      
      It incorrectly finds VGA connectors where none are attached, apparently
      not noticing that nothing replied to the EDID queries, and happily using
      the default EDID modes that have nothing to do with actual hardware.
      
      That in turn then causes X to fall down to the lowest common
      denominator, which is usually the default 1024x768 mode that is in the
      default EDID and pretty much anything supports).
      
      I'd suggest that if not relying on the HDP pin, the code should at least
      check whether it gets valid EDID data back, rather than just assume
      there's something on the VGA connector.
      
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f53369b
  4. 08 6月, 2012 1 次提交
  5. 07 6月, 2012 5 次提交
  6. 06 6月, 2012 2 次提交
  7. 05 6月, 2012 14 次提交
  8. 04 6月, 2012 7 次提交
  9. 03 6月, 2012 2 次提交
    • N
      target/file: Use O_DSYNC by default for FILEIO backends · a4dff304
      Nicholas Bellinger 提交于
      Convert to use O_DSYNC for all cases at FILEIO backend creation time to
      avoid the extra syncing of pure timestamp updates with legacy O_SYNC during
      default operation as recommended by hch.  Continue to do this independently of
      Write Cache Enable (WCE) bit, as WCE=0 is currently the default for all backend
      devices and enabled by user on per device basis via attrib/emulate_write_cache.
      
      This patch drops the now unnecessary fd_buffered_io= token usage that was
      originally signalling when to explictly disable O_SYNC at backend creation
      time for buffered I/O operation.  This can end up being dangerous for a number
      of reasons during physical node failure, so go ahead and drop this option
      for now when O_DSYNC is used as the default.
      
      Also allow explict FUA WRITEs -> vfs_fsync_range() call to function in
      fd_execute_cmd() independently of WCE bit setting.
      Reported-by: NChristoph Hellwig <hch@lst.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      a4dff304
    • J
      dm thin: provide userspace access to pool metadata · cc8394d8
      Joe Thornber 提交于
      This patch implements two new messages that can be sent to the thin
      pool target allowing it to take a snapshot of the _metadata_.  This,
      read-only snapshot can be accessed by userland, concurrently with the
      live target.
      
      Only one metadata snapshot can be held at a time.  The pool's status
      line will give the block location for the current msnap.
      
      Since version 0.1.5 of the userland thin provisioning tools, the
      thin_dump program displays the msnap as follows:
      
          thin_dump -m <msnap root> <metadata dev>
      
      Available here: https://github.com/jthornber/thin-provisioning-tools
      
      Now that userland can access the metadata we can do various things
      that have traditionally been kernel side tasks:
      
           i) Incremental backups.
      
           By using metadata snapshots we can work out what blocks have
           changed over time.  Combined with data snapshots we can ensure
           the data doesn't change while we back it up.
      
           A short proof of concept script can be found here:
      
           https://github.com/jthornber/thinp-test-suite/blob/master/incremental_backup_example.rb
      
           ii) Migration of thin devices from one pool to another.
      
           iii) Merging snapshots back into an external origin.
      
           iv) Asyncronous replication.
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      cc8394d8