linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oded Gabbay <ogabbay@kernel.org>
To: gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org
Subject: [git pull] habanalabs fixes for 5.11-rc4
Date: Wed, 13 Jan 2021 09:52:53 +0200	[thread overview]
Message-ID: <20210113075253.GA27799@CORE.localdomain> (raw)

Hi Greg,

This pull request contains three important bug fixes for 5.11-rc4.
Basically the driver won't work without the dma address fix, and 
IMO the two other fixes are also improtant enough to be included 
at this stage.

Thanks,
Oded

The following changes since commit f970d1d01af8606233f47901c1cf39f3ae21fd74:

  Merge tag 'phy-fixes-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy into char-misc-next (2021-01-11 15:37:40 +0100)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git tags/misc-habanalabs-fixes-2021-01-13

for you to fetch changes up to 9488307a5559255f2fc9a3ab61e1c31e243ca7c6:

  habanalabs: prevent soft lockup during unmap (2021-01-12 15:00:10 +0200)

----------------------------------------------------------------
This tag contains the following bug fixes:

- Fix the dma address that is passed to dma_mmap_coherent. We passed
  an address that includes an offset that is needed by our device and
  that caused dma_mmap_coherent to do an errounous mapping.

- Fix the reset process in case failures happen during the reset process.
  Without this fix, if the user would have asked to perform reset after
  the previous reset failed he would get a kernel panic

- WA to prevent soft lockup BUG during unmap of host memory. In case of
  tens of thousands of mappings, the unmapping can take a long time that
  exceeds the soft lockup timeout. This WA adds a small sleep every 32K
  page unmappings to prevent that.

----------------------------------------------------------------
Oded Gabbay (3):
      habanalabs: fix dma_addr passed to dma_mmap_coherent
      habanalabs: fix reset process in case of failures
      habanalabs: prevent soft lockup during unmap

 drivers/misc/habanalabs/common/device.c     |  2 +-
 drivers/misc/habanalabs/common/habanalabs.h |  1 +
 drivers/misc/habanalabs/common/memory.c     | 10 ++++++++--
 drivers/misc/habanalabs/common/mmu.c        |  6 +++---
 drivers/misc/habanalabs/common/mmu_v1.c     | 12 ++++++++++--
 drivers/misc/habanalabs/gaudi/gaudi.c       |  3 ++-
 drivers/misc/habanalabs/goya/goya.c         |  3 ++-
 7 files changed, 27 insertions(+), 10 deletions(-)

             reply	other threads:[~2021-01-13  7:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13  7:52 Oded Gabbay [this message]
2021-01-13  9:52 ` [git pull] habanalabs fixes for 5.11-rc4 Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210113075253.GA27799@CORE.localdomain \
    --to=ogabbay@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).