Skip to content
  1. Oct 07, 2014
  2. Sep 29, 2014
    • Rafał Miłecki's avatar
      mtd: move support for struct flash_platform_data into m25p80 · 32f1b7c8
      Rafał Miłecki authored
      
      
      This "type" seems to be an extra hint for m25p80 about the flash. Some
      archs register flash_platform_data with "name" set to "m25p80" and then
      with a real flash name set in "type". It seems to be a trick specific
      to the m25p80 so let's move it out of spi-nor.
      Btw switch to the spi_nor_match_id instead of iterating spi_nor_ids.
      
      Signed-off-by: default avatarRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      32f1b7c8
    • Rafał Miłecki's avatar
      mtd: spi-nor: add Kconfig option to disable 4K sectors · 57cf26c1
      Rafał Miłecki authored
      
      
      Current situation with 4K sectors is quite messy. First of all, some
      MTD "users" don't work with such small size. An example may be UBIFS
      which requires 15 KiB erase blocks as a minimum. In theory spi-nor
      should provide multiple erase regions and MTD "users" should use the
      one they need. Unforunately that is not implemented.
      
      In the result our flashes database in spi-nor is hackish. For some
      flashes we pretend they don't support 4K sectors just because some
      distribution uses UBIFS on it. This ofc leads to conflicts, like
      Samsung using w25q128 with 4K sectors vs. OpenWrt requiring it to
      pretend it's 64 KiB blocks only.
      
      My idea (plan?) for fixing this situation:
      1) Use real hw info (this requires a way for disabling 4K for now)
      2) Provide detailed info about erase regions
      3) Make UBIFS work with devices that support 4K sectors
      
      Signed-off-by: default avatarRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      57cf26c1
  3. Sep 23, 2014
  4. Sep 20, 2014
  5. Sep 18, 2014
  6. Sep 17, 2014
  7. Sep 16, 2014
  8. Sep 15, 2014
    • Linus Torvalds's avatar
      Linux 3.17-rc5 · 9e82bf01
      Linus Torvalds authored
      9e82bf01
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 83373f70
      Linus Torvalds authored
      Pull vfs fixes from Al Viro:
       "double iput() on failure exit in lustre, racy removal of spliced
        dentries from ->s_anon in __d_materialise_dentry() plus a bunch of
        assorted RCU pathwalk fixes"
      
      The RCU pathwalk fixes end up fixing a couple of cases where we
      incorrectly dropped out of RCU walking, due to incorrect initialization
      and testing of the sequence locks in some corner cases.  Since dropping
      out of RCU walk mode forces the slow locked accesses, those corner cases
      slowed down quite dramatically.
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        be careful with nd->inode in path_init() and follow_dotdot_rcu()
        don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()
        fix bogus read_seqretry() checks introduced in b37199e6
        move the call of __d_drop(anon) into __d_materialise_unique(dentry, anon)
        [fix] lustre: d_make_root() does iput() on dentry allocation failure
      83373f70
    • Linus Torvalds's avatar
      vfs: avoid non-forwarding large load after small store in path lookup · 9226b5b4
      Linus Torvalds authored
      The performance regression that Josef Bacik reported in the pathname
      lookup (see commit 99d263d4
      
       "vfs: fix bad hashing of dentries") made
      me look at performance stability of the dcache code, just to verify that
      the problem was actually fixed.  That turned up a few other problems in
      this area.
      
      There are a few cases where we exit RCU lookup mode and go to the slow
      serializing case when we shouldn't, Al has fixed those and they'll come
      in with the next VFS pull.
      
      But my performance verification also shows that link_path_walk() turns
      out to have a very unfortunate 32-bit store of the length and hash of
      the name we look up, followed by a 64-bit read of the combined hash_len
      field.  That screws up the processor store to load forwarding, causing
      an unnecessary hickup in this critical routine.
      
      It's caused by the ugly calling convention for the "hash_name()"
      function, and easily fixed by just making hash_name() fill in the whole
      'struct qstr' rather than passing it a pointer to just the hash value.
      
      With that, the profile for this function looks much smoother.
      
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9226b5b4
    • Linus Torvalds's avatar
      Merge branch 'parisc-3.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 5910cfdc
      Linus Torvalds authored
      Pull parisc updates from Helge Deller:
       "The most important patch is a new Light Weigth Syscall (LWS) for 8,
        16, 32 and 64 bit atomic CAS operations which is required in order to
        be able to implement the atomic gcc builtins on our platform.
      
        Other than that, we wire up the seccomp, getrandom and memfd_create
        syscalls, fixes a minor off-by-one bug and a wrong printk string"
      
      * 'parisc-3.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Implement new LWS CAS supporting 64 bit operations.
        parisc: Wire up seccomp, getrandom and memfd_create syscalls
        parisc: dino: fix %d confusingly prefixed with 0x in format string
        parisc: sys_hpux: NUL terminator is one past the end
      5910cfdc
    • Al Viro's avatar
      be careful with nd->inode in path_init() and follow_dotdot_rcu() · 4023bfc9
      Al Viro authored
      
      
      in the former we simply check if dentry is still valid after picking
      its ->d_inode; in the latter we fetch ->d_inode in the same places
      where we fetch dentry and its ->d_seq, under the same checks.
      
      Cc: stable@vger.kernel.org # 2.6.38+
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      4023bfc9
    • Al Viro's avatar
      don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu() · 7bd88377
      Al Viro authored
      
      
      return the value instead, and have path_init() do the assignment.  Broken by
      "vfs: Fix absolute RCU path walk failures due to uninitialized seq number",
      which was Cc-stable with 2.6.38+ as destination.  This one should go where
      it went.
      
      To avoid dummy value returned in case when root is already set (it would do
      no harm, actually, since the only caller that doesn't ignore the return value
      is guaranteed to have nd->root *not* set, but it's more obvious that way),
      lift the check into callers.  And do the same to set_root(), to keep them
      in sync.
      
      Cc: stable@vger.kernel.org # 2.6.38+
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      7bd88377
    • Linus Torvalds's avatar
      Merge tag 'ntb-3.17' of git://github.com/jonmason/ntb · 02c1be3d
      Linus Torvalds authored
      Pull ntb driver bugfixes from Jon Mason:
       "NTB driver fixes for queue spread and buffer alignment.  Also, update
        to MAINTAINERS to reflect new e-mail address"
      
      * tag 'ntb-3.17' of git://github.com/jonmason/ntb:
        ntb: Add alignment check to meet hardware requirement
        MAINTAINERS: update NTB info
        NTB: correct the spread of queues over mw's
      02c1be3d