1. 29 11月, 2016 4 次提交
    • L
      Merge branch 'for-4.9-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata · 88abd824
      Linus Torvalds 提交于
      Pull libata fixes from Tejun Heo:
       "The recent changes in ahci MSI handling need one more fix.  Hopefully,
        this restores parity with before.
      
        The other two are minor fixes with both low impact and risk"
      
      * 'for-4.9-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
        ahci: always fall back to single-MSI mode
        libata-scsi: Fixup ata_gen_passthru_sense()
        mvsas: fix error return code in mvs_task_prep()
      88abd824
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc · 96e52d3a
      Linus Torvalds 提交于
      Pull sparc fixes from David Miller:
       "Two ugly build warning fixes"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
        dbri: Fix compiler warning
        qlogicpti: Fix compiler warnings
      96e52d3a
    • T
      dbri: Fix compiler warning · 16f46050
      Tushar Dave 提交于
      dbri uses 'u32' for dma handle while invoking kernel DMA APIs,
      instead of using dma_addr_t. This hasn't caused any 'incompatible
      pointer type' warning on SPARC because until now dma_addr_t is of
      type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit
      DMA and therefore dma_addr_t became of type u64. This makes
      'incompatible pointer type' warnings inevitable.
      
      e.g.
      sound/sparc/dbri.c: In function ‘snd_dbri_create’:
      sound/sparc/dbri.c:2538: warning: passing argument 3 of ‘dma_zalloc_coherent’ from incompatible pointer type
      ./include/linux/dma-mapping.h:608: note: expected ‘dma_addr_t *’ but argument is of type ‘u32 *’
      
      For the record, dbri(sbus) driver never executes on sun4v. Therefore
      even though 64bit DMA is enabled on SPARC, dbri continues to use
      legacy iommu that guarantees DMA address is always in 32bit range.
      
      This patch resolves above compiler warning.
      Signed-off-by: NTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: Nthomas tai <thomas.tai@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16f46050
    • T
      qlogicpti: Fix compiler warnings · e58566b1
      Tushar Dave 提交于
      qlogicpti uses '__u32' for dma handle while invoking kernel DMA APIs,
      instead of using dma_addr_t. This hasn't caused any 'incompatible
      pointer type' warning on SPARC because until now dma_addr_t is of
      type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit
      DMA and therefore dma_addr_t became of type u64. This makes
      'incompatible pointer type' warnings inevitable.
      
      e.g.
      drivers/scsi/qlogicpti.c: In function ‘qpti_map_queues’:
      drivers/scsi/qlogicpti.c:813: warning: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type
      ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument is of type ‘__u32 *’
      drivers/scsi/qlogicpti.c:822: warning: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type
      ./include/linux/dma-mapping.h:445: note: expected ‘dma_addr_t *’ but argument is of type ‘__u32 *’
      
      For the record, qlogicpti never executes on sun4v. Therefore even
      though 64bit DMA is enabled on SPARC, qlogicpti continues to use
      legacy iommu that guarantees DMA address is always in 32bit range.
      
      This patch resolves aforementioned compiler warnings.
      Signed-off-by: NTushar Dave <tushar.n.dave@oracle.com>
      Reviewed-by: Nthomas tai <thomas.tai@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e58566b1
  2. 28 11月, 2016 3 次提交
  3. 27 11月, 2016 8 次提交
  4. 26 11月, 2016 22 次提交
  5. 25 11月, 2016 3 次提交
    • J
      parisc: Also flush data TLB in flush_icache_page_asm · 5035b230
      John David Anglin 提交于
      This is the second issue I noticed in reviewing the parisc TLB code.
      
      The fic instruction may use either the instruction or data TLB in
      flushing the instruction cache.  Thus, on machines with a split TLB, we
      should also flush the data TLB after setting up the temporary alias
      registers.
      
      Although this has no functional impact, I changed the pdtlb and pitlb
      instructions to consistently use the index register %r0.  These
      instructions do not support integer displacements.
      
      Tested on rp3440 and c8000.
      Signed-off-by: NJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      5035b230
    • J
      parisc: Fix race in pci-dma.c · c0452fb9
      John David Anglin 提交于
      We are still troubled by occasional random segmentation faults and
      memory memory corruption on SMP machines.  The causes quite a few
      package builds to fail on the Debian buildd machines for parisc.  When
      gcc-6 failed to build three times in a row, I looked again at the TLB
      related code.  I found a couple of issues.  This is the first.
      
      In general, we need to ensure page table updates and corresponding TLB
      purges are atomic.  The attached patch fixes an instance in pci-dma.c
      where the page table update was not guarded by the TLB lock.
      
      Tested on rp3440 and c8000.  So far, no further random segmentation
      faults have been observed.
      Signed-off-by: NJohn David Anglin  <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      c0452fb9
    • H
      parisc: Switch to generic sched_clock implementation · 43b1f6ab
      Helge Deller 提交于
      Drop the open-coded sched_clock() function and replace it by the provided
      GENERIC_SCHED_CLOCK implementation.  We have seen quite some hung tasks in the
      past, which seem to be fixed by this patch.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      43b1f6ab