1. 19 1月, 2017 6 次提交
  2. 11 1月, 2017 1 次提交
  3. 05 1月, 2017 3 次提交
  4. 20 12月, 2016 2 次提交
    • V
      ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcache · 08fe0079
      Vineet Gupta 提交于
      An ARC700 customer reported linux boot crashes when upgrading to bigger
      L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and
      current code only assumed 2 colours, while theirs had 4. So default to 4
      colours and complain if there are fewer. Ideally this needs to be a
      Kconfig option, but heck that's too much of hassle for a single user.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      08fe0079
    • V
      ARC: mm: No need to save cache version in @cpuinfo · f64915be
      Vineet Gupta 提交于
      Historical MMU revisions have been paired with Cache revision updates
      which are captured in MMU and Cache Build Configuration Registers respectively.
      
      This was used in boot code to check for configurations mismatches,
      speically in simulations (such as running with non existent caches,
      non pairing MMU and Cache version etc). This can instead be inferred
      from other cache params such as line size. So remove @ver from post
      processed @cpuinfo which could be used later to save soem other
      interesting info.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      f64915be
  5. 19 12月, 2016 1 次提交
  6. 15 12月, 2016 3 次提交
    • A
      arch/arc: add option to skip sync on DMA mapping · 8a3385d2
      Alexander Duyck 提交于
      Patch series "Add support for DMA writable pages being writable by the
      network stack", v3.
      
      The first 19 patches in the set add support for the DMA attribute
      DMA_ATTR_SKIP_CPU_SYNC on multiple platforms/architectures.  This is
      needed so that we can flag the calls to dma_map/unmap_page so that we do
      not invalidate cache lines that do not currently belong to the device.
      Instead we have to take care of this in the driver via a call to
      sync_single_range_for_cpu prior to freeing the Rx page.
      
      Patch 20 adds support for dma_map_page_attrs and dma_unmap_page_attrs so
      that we can unmap and map a page using the DMA_ATTR_SKIP_CPU_SYNC
      attribute.
      
      Patch 21 adds support for freeing a page that has multiple references
      being held by a single caller.  This way we can free page fragments that
      were allocated by a given driver.
      
      The last 2 patches use these updates in the igb driver, and lay the
      groundwork to allow for us to reimplement the use of build_skb.
      
      This patch (of 23):
      
      This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
      avoid invoking cache line invalidation if the driver will just handle it
      later via a sync_for_cpu or sync_for_device call.
      
      Link: http://lkml.kernel.org/r/20161110113419.76501.38491.stgit@ahduyck-blue-test.jf.intel.comSigned-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8a3385d2
    • V
      ARCv2: intc: default all interrupts to priority 1 · 107177b1
      Vineet Gupta 提交于
      ARC HS Cores support configurable multiple interrupt priorities of upto
      16 levels. In commit dec2b284 ("ARCv2: intc: Allow interruption by
      lowest priority interrupt") we switched to 15 which seems a bit
      excessive given that there would be rare hardware implementing so many
      preemption levels AND running Linux. It would seem that 2 levels will be
      more common so switch to 1 as the default priority level. This will be
      the "lower" priority level saving 0 for implementing NMI style support.
      
      This scheme also works in systems with more than 2 prioity levels as
      well.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      107177b1
    • V
      ARCv2: entry: document intr disable in hard isr · 78833e79
      Vineet Gupta 提交于
      And while at it - use the proper assembler macro which includes the
      optional irq tracing already - de-uglify'ing the code a bit
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      78833e79
  7. 14 12月, 2016 1 次提交
  8. 01 12月, 2016 11 次提交
  9. 30 11月, 2016 2 次提交
  10. 29 11月, 2016 2 次提交
  11. 17 11月, 2016 1 次提交
  12. 16 11月, 2016 2 次提交
    • C
      locking/core, arch: Remove cpu_relax_lowlatency() · 5bd0b85b
      Christian Borntraeger 提交于
      As there are no users left, we can remove cpu_relax_lowlatency()
      implementations from every architecture.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: xen-devel@lists.xenproject.org
      Cc: <linux-arch@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1477386195-32736-6-git-send-email-borntraeger@de.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5bd0b85b
    • C
      locking/core: Introduce cpu_relax_yield() · 79ab11cd
      Christian Borntraeger 提交于
      For spinning loops people do often use barrier() or cpu_relax().
      For most architectures cpu_relax and barrier are the same, but on
      some architectures cpu_relax can add some latency.
      For example on power,sparc64 and arc, cpu_relax can shift the CPU
      towards other hardware threads in an SMT environment.
      On s390 cpu_relax does even more, it uses an hypercall to the
      hypervisor to give up the timeslice.
      In contrast to the SMT yielding this can result in larger latencies.
      In some places this latency is unwanted, so another variant
      "cpu_relax_lowlatency" was introduced. Before this is used in more
      and more places, lets revert the logic and provide a cpu_relax_yield
      that can be called in places where yielding is more important than
      latency. By default this is the same as cpu_relax on all architectures.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1477386195-32736-2-git-send-email-borntraeger@de.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      79ab11cd
  13. 12 11月, 2016 1 次提交
    • A
      Kbuild: enable -Wmaybe-uninitialized warning for "make W=1" · a76bcf55
      Arnd Bergmann 提交于
      Traditionally, we have always had warnings about uninitialized variables
      enabled, as this is part of -Wall, and generally a good idea [1], but it
      also always produced false positives, mainly because this is a variation
      of the halting problem and provably impossible to get right in all cases
      [2].
      
      Various people have identified cases that are particularly bad for false
      positives, and in commit e74fc973 ("Turn off -Wmaybe-uninitialized
      when building with -Os"), I turned off the warning for any build that
      was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
      of false positive warnings in the default build but unfortunately had
      the side effect of turning the warning off completely in 'allmodconfig'
      builds, which in turn led to a lot of warnings (both actual bugs, and
      remaining false positives) to go in unnoticed.
      
      With commit 877417e6 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
      definition") enabled the warning again for allmodconfig builds in v4.7
      and in v4.8-rc1, I had finally managed to address all warnings I get in
      an ARM allmodconfig build and most other maybe-uninitialized warnings
      for ARM randconfig builds.
      
      However, commit 6e8d666e ("Disable "maybe-uninitialized" warning
      globally") was merged at the same time and disabled it completely for
      all configurations, because of false-positive warnings on x86 that I had
      not addressed until then.  This caused a lot of actual bugs to get
      merged into mainline, and I sent several dozen patches for these during
      the v4.9 development cycle.  Most of these are actual bugs, some are for
      correct code that is safe because it is only called under external
      constraints that make it impossible to run into the case that gcc sees,
      and in a few cases gcc is just stupid and finds something that can
      obviously never happen.
      
      I have now done a few thousand randconfig builds on x86 and collected
      all patches that I needed to address every single warning I got (I can
      provide the combined patch for the other warnings if anyone is
      interested), so I hope we can get the warning back and let people catch
      the actual bugs earlier.
      
      This reverts the change to disable the warning completely and for now
      brings it back at the "make W=1" level, so we can get it merged into
      mainline without introducing false positives.  A follow-up patch enables
      it on all levels unless some configuration option turns it off because
      of false-positives.
      
      Link: https://rusty.ozlabs.org/?p=232 [1]
      Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a76bcf55
  14. 09 11月, 2016 4 次提交