1. 20 1月, 2015 5 次提交
  2. 15 1月, 2015 1 次提交
  3. 14 1月, 2015 2 次提交
  4. 12 1月, 2015 1 次提交
    • A
      mmc: sdhci: Disable re-tuning for HS400 · b5540ce1
      Adrian Hunter 提交于
      Re-tuning for HS400 mode must be done in HS200
      mode. Currently there is no support for that.
      That needs to be reflected in the code.
      Specifically, if tuning is executed in HS400 mode
      then return an error, and do not start the
      tuning timer if HS200 tuning is being done prior
      to switching to HS400.
      
      Note that periodic re-tuning is not expected
      to be needed for HS400 but re-tuning is still
      needed after the host controller has lost power.
      In the case of suspend/resume that is not necessary
      because the card is fully re-initialised. That
      just leaves runtime suspend/resume with no support
      for HS400 re-tuning.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      b5540ce1
  5. 09 1月, 2015 5 次提交
  6. 08 1月, 2015 5 次提交
  7. 07 1月, 2015 1 次提交
    • L
      mm: propagate error from stack expansion even for guard page · fee7e49d
      Linus Torvalds 提交于
      Jay Foad reports that the address sanitizer test (asan) sometimes gets
      confused by a stack pointer that ends up being outside the stack vma
      that is reported by /proc/maps.
      
      This happens due to an interaction between RLIMIT_STACK and the guard
      page: when we do the guard page check, we ignore the potential error
      from the stack expansion, which effectively results in a missing guard
      page, since the expected stack expansion won't have been done.
      
      And since /proc/maps explicitly ignores the guard page (commit
      d7824370: "mm: fix up some user-visible effects of the stack guard
      page"), the stack pointer ends up being outside the reported stack area.
      
      This is the minimal patch: it just propagates the error.  It also
      effectively makes the guard page part of the stack limit, which in turn
      measn that the actual real stack is one page less than the stack limit.
      
      Let's see if anybody notices.  We could teach acct_stack_growth() to
      allow an extra page for a grow-up/grow-down stack in the rlimit test,
      but I don't want to add more complexity if it isn't needed.
      Reported-and-tested-by: NJay Foad <jay.foad@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fee7e49d
  8. 06 1月, 2015 2 次提交
  9. 30 12月, 2014 1 次提交
    • M
      mm: get rid of radix tree gfp mask for pagecache_get_page · 45f87de5
      Michal Hocko 提交于
      Commit 2457aec6 ("mm: non-atomically mark page accessed during page
      cache allocation where possible") has added a separate parameter for
      specifying gfp mask for radix tree allocations.
      
      Not only this is less than optimal from the API point of view because it
      is error prone, it is also buggy currently because
      grab_cache_page_write_begin is using GFP_KERNEL for radix tree and if
      fgp_flags doesn't contain FGP_NOFS (mostly controlled by fs by
      AOP_FLAG_NOFS flag) but the mapping_gfp_mask has __GFP_FS cleared then
      the radix tree allocation wouldn't obey the restriction and might
      recurse into filesystem and cause deadlocks.  This is the case for most
      filesystems unfortunately because only ext4 and gfs2 are using
      AOP_FLAG_NOFS.
      
      Let's simply remove radix_gfp_mask parameter because the allocation
      context is same for both page cache and for the radix tree.  Just make
      sure that the radix tree gets only the sane subset of the mask (e.g.  do
      not pass __GFP_WRITE).
      
      Long term it is more preferable to convert remaining users of
      AOP_FLAG_NOFS to use mapping_gfp_mask instead and simplify this
      interface even further.
      Reported-by: NDave Chinner <david@fromorbit.com>
      Signed-off-by: NMichal Hocko <mhocko@suse.cz>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      45f87de5
  10. 27 12月, 2014 2 次提交
    • J
      netlink/genetlink: pass network namespace to bind/unbind · 023e2cfa
      Johannes Berg 提交于
      Netlink families can exist in multiple namespaces, and for the most
      part multicast subscriptions are per network namespace. Thus it only
      makes sense to have bind/unbind notifications per network namespace.
      
      To achieve this, pass the network namespace of a given client socket
      to the bind/unbind functions.
      
      Also do this in generic netlink, and there also make sure that any
      bind for multicast groups that only exist in init_net is rejected.
      This isn't really a problem if it is accepted since a client in a
      different namespace will never receive any notifications from such
      a group, but it can confuse the family if not rejected (it's also
      possible to silently (without telling the family) accept it, but it
      would also have to be ignored on unbind so families that take any
      kind of action on bind/unbind won't do unnecessary work for invalid
      clients like that.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      023e2cfa
    • J
      net: Generalize ndo_gso_check to ndo_features_check · 5f35227e
      Jesse Gross 提交于
      GSO isn't the only offload feature with restrictions that
      potentially can't be expressed with the current features mechanism.
      Checksum is another although it's a general issue that could in
      theory apply to anything. Even if it may be possible to
      implement these restrictions in other ways, it can result in
      duplicate code or inefficient per-packet behavior.
      
      This generalizes ndo_gso_check so that drivers can remove any
      features that don't make sense for a given packet, similar to
      netif_skb_features(). It also converts existing driver
      restrictions to the new format, completing the work that was
      done to support tunnel protocols since the issues apply to
      checksums as well.
      
      By actually removing features from the set that are used to do
      offloading, it solves another problem with the existing
      interface. In these cases, GSO would run with the original set
      of features and not do anything because it appears that
      segmentation is not required.
      
      CC: Tom Herbert <therbert@google.com>
      CC: Joe Stringer <joestringer@nicira.com>
      CC: Eric Dumazet <edumazet@google.com>
      CC: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      Acked-by: NTom Herbert <therbert@google.com>
      Fixes: 04ffcb25 ("net: Add ndo_gso_check")
      Tested-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f35227e
  11. 24 12月, 2014 1 次提交
    • R
      audit: restore AUDIT_LOGINUID unset ABI · 041d7b98
      Richard Guy Briggs 提交于
      A regression was caused by commit 780a7654:
      	 audit: Make testing for a valid loginuid explicit.
      (which in turn attempted to fix a regression caused by e1760bd5)
      
      When audit_krule_to_data() fills in the rules to get a listing, there was a
      missing clause to convert back from AUDIT_LOGINUID_SET to AUDIT_LOGINUID.
      
      This broke userspace by not returning the same information that was sent and
      expected.
      
      The rule:
      	auditctl -a exit,never -F auid=-1
      gives:
      	auditctl -l
      		LIST_RULES: exit,never f24=0 syscall=all
      when it should give:
      		LIST_RULES: exit,never auid=-1 (0xffffffff) syscall=all
      
      Tag it so that it is reported the same way it was set.  Create a new
      private flags audit_krule field (pflags) to store it that won't interact with
      the public one from the API.
      
      Cc: stable@vger.kernel.org # v3.10-rc1+
      Signed-off-by: NRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      041d7b98
  12. 23 12月, 2014 1 次提交
    • V
      phy: phy-ti-pipe3: fix inconsistent enumeration of PCIe gen2 cards · 0bc09f9c
      Vignesh R 提交于
      Prior to DRA74x silicon rev 1.1, pcie_pcs register bits 8-15 and bits 16-23
      were used to configure RC delay count for phy1 and phy2 respectively.
      phyid was used as index to distinguish the phys and to configure the delay
      values appropriately.
      
      As of DRA74x silicon rev 1.1, pcie_pcs register definition has changed.
      Bits 16-23 are used to configure delay values for *both* phy1 and phy2.
      
      Hence phyid is no longer required.
      
      So, drop id field from ti_pipe3 structure and its subsequent references
      for configuring pcie_pcs register.
      
      Also, pcie_pcs register now needs to be configured with delay value of 0x96
      at bit positions 16-23. See register description of CTRL_CORE_PCIE_PCS in
      ARM572x TRM, SPRUHZ6, October 2014, section 18.5.2.2, table 18-1804.
      
      This is needed to ensure Gen2 cards are enumerated consistently.
      
      DRA72x silicon behaves same way as DRA74x rev 1.1 as far as this functionality
      is considered.
      
      Test results on DRA74x and DRA72x EVMs:
      
      Before patch
      ------------
      DRA74x ES 1.0: Gen1 cards work, Gen2 cards do not work (expected result due to
      silicon errata)
      DRA74x ES 1.1: Gen1 cards work, Gen2 cards do not work sometimes due to incorrect
      programming of register
      
      DRA72x: Gen1 cards work, Gen2 cards do not work sometimes due to incorrect
      programming of register
      
      After patch
      -----------
      DRA74x ES 1.0: Gen1 cards work, Gen2 cards do not work (expected result due to
      silicon errata)
      DRA74x ES 1.1: Gen1 cards work, Gen2 cards work consistently.
      
      DRA72x: Gen1 and Gen2 cards enumerate consistently.
      Signed-off-by: NVignesh R <vigneshr@ti.com>
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      0bc09f9c
  13. 21 12月, 2014 1 次提交
  14. 20 12月, 2014 1 次提交
  15. 19 12月, 2014 1 次提交
    • P
      mm: cma: split cma-reserved in dmesg log · e48322ab
      Pintu Kumar 提交于
      When the system boots up, in the dmesg logs we can see the memory
      statistics along with total reserved as below.  Memory: 458840k/458840k
      available, 65448k reserved, 0K highmem
      
      When CMA is enabled, still the total reserved memory remains the same.
      However, the CMA memory is not considered as reserved.  But, when we see
      /proc/meminfo, the CMA memory is part of free memory.  This creates
      confusion.  This patch corrects the problem by properly subtracting the
      CMA reserved memory from the total reserved memory in dmesg logs.
      
      Below is the dmesg snapshot from an arm based device with 512MB RAM and
      12MB single CMA region.
      
      Before this change:
        Memory: 458840k/458840k available, 65448k reserved, 0K highmem
      
      After this change:
        Memory: 458840k/458840k available, 53160k reserved, 12288k cma-reserved, 0K highmem
      Signed-off-by: NPintu Kumar <pintu.k@samsung.com>
      Signed-off-by: NVishnu Pratap Singh <vishnu.ps@samsung.com>
      Acked-by: NMichal Nazarewicz <mina86@mina86.com>
      Cc: Rafael Aquini <aquini@redhat.com>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e48322ab
  16. 18 12月, 2014 10 次提交