1. 03 Jun, 2015 10 commits
  2. 02 Jun, 2015 28 commits
  3. 28 May, 2015 2 commits
    • Thomas Petazzoni's avatar
      ARM: mvebu: do not register custom DMA operations when coherency is disabled · 3a5f8103
      Thomas Petazzoni authored
      This patch is a partial backport of commit ef01c6c3 ("ARM: mvebu:
      remove Armada 375 Z1 workaround for I/O coherency"). This commit was
      merged in v3.19, so kernel versions later than v3.19 are not affected
      by the problem that this commit fixes.
      
      It does not make a lot of sense to backport this commit entirely,
      since it is mainly removing some no longer useful code. However, this
      commit is also making sure that the bus_register_notifier that
      register the custom DMA operations that should be used for HW I/O
      coherency does not get registered when said HW I/O coherency is not
      enabled.
      
      This is particularly critical since we have decided to disable HW I/O
      coherency completely in all kernels < 4.0, to be on the safe side,
      while experimenting a new implementation of the HW I/O coherency in >=
      4.0.
      
      Without this commit, kernels earlier than 3.18 have the custom DMA
      operations normally used for HW I/O coherency registered (they don't
      do cache maintenance operations), while HW I/O coherency is
      disabled. It essentially causes every DMA transfer to transfer
      garbage.
      
      The issue fixed by this commit was introduced by 5ab5afd8 ("ARM:
      mvebu: implement Armada 375 coherency workaround"), but it was not
      visible until now since it didn't cause any problem when HW I/O
      coherency is enabled.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Bjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3a5f8103
    • Chen Gang's avatar
      qla2xxx: remove redundant declaration in 'qla_gbl.h' · 2bf2d29e
      Chen Gang authored
      commit 9493c242 upstream.
      
      Remove 2 redundant extern inline functions: qla8044_set_qsnt_ready() and
      qla8044_need_reset_handler(). At present, within upstream next kernel
      source code, they are only used within "drivers/scsi/qla2xxx/qla_nx2.c".
      
      The related error and warnings (with allmodconfig under tile):
      
          CC [M]  drivers/scsi/qla2xxx/qla_nx2.o
        drivers/scsi/qla2xxx/qla_nx2.c:1633:1: error: static declaration of 'qla8044_need_reset_handler' follows non-static declaration
         qla8044_need_reset_handler(struct scsi_qla_host *vha)
         ^
        In file included from drivers/scsi/qla2xxx/qla_def.h:3706:0,
                         from drivers/scsi/qla2xxx/qla_nx2.c:11:
        drivers/scsi/qla2xxx/qla_gbl.h:756:20: note: previous declaration of 'qla8044_need_reset_handler' was here
         extern inline void qla8044_need_reset_handler(struct scsi_qla_host *vha);
                            ^
        drivers/scsi/qla2xxx/qla_gbl.h:756:20: warning: inline function 'qla8044_need_reset_handler' declared but never defined
        make[3]: *** [drivers/scsi/qla2xxx/qla_nx2.o] Error 1
        make[2]: *** [drivers/scsi/qla2xxx] Error 2
        make[1]: *** [drivers/scsi] Error 2
        make: *** [drivers] Error 2
      
          CC [M]  drivers/scsi/qla2xxx/qla_tmpl.o
        In file included from drivers/scsi/qla2xxx/qla_def.h:3706:0,
                         from drivers/scsi/qla2xxx/qla_tmpl.c:7:
        drivers/scsi/qla2xxx/qla_gbl.h:755:20: warning: inline function 'qla8044_set_qsnt_ready' declared but never defined
         extern inline void qla8044_set_qsnt_ready(struct scsi_qla_host *vha);
                          ^
      Signed-off-by: default avatarChen Gang <gang.chen.5i5j@gmail.com>
      Acked-by: default avatarSaurav Kashyap <saurav.kashyap@qlogic.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Philip Müller <philm@manjaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2bf2d29e