Now that invert_gpio arguments are unused, let's remove them.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/64d766d1f8af2e22bce32f4ffa453f7234207ad6.1576031637.git.mirq-linux@rere.qmqm.plSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

There are a few places around the code that invert inverted and possibly
inverted CD line. That's really confusing. Squash them all into one place
in mmc_gpiod_request_cd(). MMC_CAP2_CD_ACTIVE_HIGH is used analogously to
WP line: in GPIO mode it is used only at probe time to switch polarity, for
native mode it is left as is.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/db189b715596d63caf8c6a088bddc71dd69a879b.1576031637.git.mirq-linux@rere.qmqm.plSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use MMC_CAP2_RO_ACTIVE_HIGH flag as indicator if GPIO line is to be
inverted compared to DT/platform-specified polarity. The flag is not used
after init in GPIO mode anyway. No functional changes intended.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/a60f563f11bbff821da2fa2949ca82922b144860.1576031637.git.mirq-linux@rere.qmqm.plSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add possibility to toggle active-low flag of a gpio descriptor. This is
useful for compatibility code, where defaults are inverted vs DT gpio
flags or the active-low flag is taken from elsewhere.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/7ce0338e01ad17fa5a227176813941b41a7c35c1.1576031637.git.mirq-linux@rere.qmqm.plSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/3f12c2deaae9e77a5e7ab8415db7751a27bc3b98.1575916477.git.mirq-linux@rere.qmqm.plSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The driver forgets to call pci_release_regions() in probe failure
and remove.
Add the missed calls to fix it.
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20191206075408.18355-1-hslester96@gmail.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Let's drop the boilerplate code for managing the default pinctrl state and
convert into using the new pinctrl_select_default_state().

Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191206170821.29711-10-ulf.hansson@linaro.org

Let's move away from using pinctrl_pm_select_default_state() as it's
scheduled for removal and use pinctrl_select_default_state() instead.

Cc: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NPaul Cercueil <paul@crapouillou.net>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191206170821.29711-9-ulf.hansson@linaro.org

Let's move away from using pinctrl_pm_select_default_state() as it's
scheduled for removal and use pinctrl_select_default_state() instead.

Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191206170821.29711-8-ulf.hansson@linaro.org

Let's drop the boilerplate code for managing the default pinctrl state and
convert into using the new pinctrl_select_default_state().

Cc: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191206170821.29711-7-ulf.hansson@linaro.org

Let's drop the boilerplate code for managing the default pinctrl state and
convert into using the new pinctrl_select_default_state().

Additionally, move away from using pinctrl_pm_select_default_state() as
it's scheduled for removal and use pinctrl_select_default_state() instead.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191206170821.29711-6-ulf.hansson@linaro.org

Let's drop the boilerplate code for managing the default pinctrl state and
convert into using the new pinctrl_select_default_state().

Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Lars Persson <lars.persson@axis.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191206170821.29711-5-ulf.hansson@linaro.org

Let's drop the boilerplate code for managing the default pinctrl state and
convert into using the new pinctrl_select_default_state().

Additionally, move away from using pinctrl_pm_select_default_state() as
it's scheduled for removal and use pinctrl_select_default_state() instead.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191206170821.29711-4-ulf.hansson@linaro.org

Let's drop the boilerplate code for managing the default pinctrl state and
convert into using the new pinctrl_select_default_state().

Cc: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191206170821.29711-3-ulf.hansson@linaro.org

Tuning support in DDR50 speed mode was added in SD Specifications Part1
Physical Layer Specification v3.01. Its not possible to distinguish
between v3.00 and v3.01 from the SCR and that is why since
commit 4324f6de ("mmc: core: enable CMD19 tuning for DDR50 mode")
tuning failures are ignored in DDR50 speed mode.

Cards compatible with v3.00 don't respond to CMD19 in DDR50 and this
error gets printed during enumeration and also if retune is triggered at
any time during operation. Update the printk level to pr_debug so that
these errors don't lead to false error reports.
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
Cc: stable@vger.kernel.org # v4.4+
Link: https://lore.kernel.org/r/20191206114326.15856-1-faiz_abbas@ti.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

New datasheets require different and new values for HS400 with 4taps or
8taps.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191203200513.1758-6-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Now that the quirks structure is accessible, we can remove the TMIO flag
for HS400 using only 4 taps. This is Renesas specific anyhow.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191203200513.1758-5-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We will need that for a later patch.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191203200513.1758-4-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The warning is not solely used for SDR104 anymore, but for all which
require tuning.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191203200513.1758-3-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The two devices next to each other are super similar, but still, let's
keep the alphanumeric sorting for easier additions later.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191203200513.1758-2-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We know now that there won't be Gen3 SoCs with both, SYS-DMAC and
internal DMAC. We removed the blacklisting for SYS-DMAC already, so we
can remove the whitelisting for internal DMAC, too. This makes adding
new SoCs easier. We keep the quirk handling, of course.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191203194859.917-1-wsa@the-dreams.deSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The STOP command is disabled for multiple blocks r/w commands
with auto CMD12, when start to send. However, if there is data
error, software still needs to send CMD12 according to SD spec.
This patch is to allow software CMD12 sending for this case.
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20191114111814.35199-1-yangbo.lu@nxp.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The code in mmc_spi_initsequence() tries to send a burst with
high chipselect and for this reason hardcodes the device into
SPI_CS_HIGH.

This is not good because the SPI_CS_HIGH flag indicates
logical "asserted" CS not always the physical level. In
some cases the signal is inverted in the GPIO library and
in that case SPI_CS_HIGH is already set, and enforcing
SPI_CS_HIGH again will actually drive it low.

Instead of hard-coding this, toggle the polarity so if the
default is LOW it goes high to assert chipselect but if it
is already high then toggle it low instead.

Cc: Phil Elwell <phil@raspberrypi.org>
Reported-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NMark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20191204152749.12652-1-linus.walleij@linaro.org
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In the SAM9x60 SoC, there are only two clocks instead of three for the
SDHCI device. The base clk is no longer provided, it is generated
internally from the mult clk.

The values of the base clk and mul in the capabilities registers may not
reflect the reality as the mult clk is a programmable clock which can take
several rates. As we can't trust those values, take them from the clock
tree and update the capabilities according to.

As we can have the same pitfall, in some cases, with the SAMA5D2 Soc,
stop relying on capabilities too.
Signed-off-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20191128074522.69706-2-ludovic.desroches@microchip.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Tuning support in DDR50 speed mode was added in SD Specifications Part1
Physical Layer Specification v3.01. Its not possible to distinguish
between v3.00 and v3.01 from the SCR and that is why since
commit 4324f6de ("mmc: core: enable CMD19 tuning for DDR50 mode")
tuning failures are ignored in DDR50 speed mode.

Cards compatible with v3.00 don't respond to CMD19 in DDR50 and this
error gets printed during enumeration and also if retune is triggered at
any time during operation. Update the printk level to pr_debug so that
these errors don't lead to false error reports.
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
Cc: stable@vger.kernel.org # v4.4+
Link: https://lore.kernel.org/r/20191206114326.15856-1-faiz_abbas@ti.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This reverts commit 5dd19552.

First, the fix seems to be plain wrong, since the erratum suggests
waiting 5ms before setting setting SYSCTL[RSTD], but this msleep()
happens after the call of sdhci_reset() which is where that bit gets
set (if SDHCI_RESET_DATA is in mask).

Second, walking the whole device tree to figure out if some node has a
"fsl,p2020-esdhc" compatible string is hugely expensive - about 70 to
100 us on our mpc8309 board. Walking the device tree is done under a
raw_spin_lock, so this is obviously really bad on an -rt system, and a
waste of time on all.

In fact, since esdhc_reset() seems to get called around 100 times per
second, that mpc8309 now spends 0.8% of its time determining that
it is not a p2020. Whether those 100 calls/s are normal or due to some
other bug or misconfiguration, regularly hitting a 100 us
non-preemptible window is unacceptable.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191204085447.27491-1-linux@rasmusvillemoes.dkSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

there is a chance that always get response CRC error after HS200 tuning,
the reason is that need set CMD_TA to 2. this modification is only for
MT8173.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Tested-by: NHsin-Yi Wang <hsinyi@chromium.org>
Cc: stable@vger.kernel.org
Fixes: 1ede5cb8 ("mmc: mediatek: Use data tune for CMD line tune")
Link: https://lore.kernel.org/r/20191204071958.18553-1-chaotian.jing@mediatek.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The DDR_CONFIG register offset got updated after a specific
minor version of sdcc V4. This offset change has not been properly
taken care of while updating register changes for sdcc V5.

Correcting proper offset for this register.
Also updating this register value to reflect the recommended RCLK
delay.
Signed-off-by: NVeerabhadrarao Badiganti <vbadigan@codeaurora.org>
Link: https://lore.kernel.org/r/0101016ea738ec72-fa0f852d-20f8-474a-80b2-4b0ef63b132c-000000@us-west-2.amazonses.com
Fixes: f1535888 ("mmc: sdhci-msm: Define new Register address map")
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This reverts commit c894e33d.

This commit aims to treat SD High speed and SDR25 as the same while
setting UHS Timings in HOST_CONTROL2 which leads to failures with some
SD cards in AM65x. Revert this commit.

The issue this commit was trying to fix can be implemented in a platform
specific callback instead of common sdhci code.

Cc: <stable@vger.kernel.org>
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20191128110422.25917-1-faiz_abbas@ti.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>

For BINDER_TYPE_PTR and BINDER_TYPE_FDA transactions, the
num_valid local was calculated incorrectly causing the
range check in binder_validate_ptr() to miss out-of-bounds
offsets.

Fixes: bde4a19f ("binder: use userspace pointer as base of buffer space")
Signed-off-by: NTodd Kjos <tkjos@google.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191213202531.55010-1-tkjos@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It has turned out that some mmc host drivers, but perhaps also others
drivers, needs to reset the pinctrl into the default state
(PINCTRL_STATE_DEFAULT). However, they can't use the existing
pinctrl_pm_select_default_state(), as that requires CONFIG_PM to be set.
This leads to open coding, as they need to look up the default state
themselves and then select it.

To avoid the open coding, let's introduce pinctrl_select_default_state()
and make it available independently of CONFIG_PM. As a matter of fact, this
makes it more consistent with the behaviour of the driver core, as it
already tries to looks up the default state during probe.

Going forward, users of pinctrl_pm_select_default_state() are encouraged to
move to pinctrl_select_default_state(), so the old API can be removed.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20191206170821.29711-2-ulf.hansson@linaro.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

When CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not defined
reserve_additional_memory() will set balloon_stats.target_pages to a
wrong value in case there are still some ballooned pages allocated via
alloc_xenballooned_pages().

This will result in balloon_process() no longer be triggered when
ballooned pages are freed in batches.
Reported-by: NNicholas Tsirakis <niko.tsirakis@gmail.com>
Signed-off-by: NJuergen Gross <jgross@suse.com>
Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: NJuergen Gross <jgross@suse.com>

Objects allocated by xen_blkif_alloc come from the 'blkif_cache' kmem
cache. This cache is destoyed when xen-blkif is unloaded so it is
necessary to wait for the deferred free routine used for such objects to
complete. This necessity was missed in commit 14855954 "xen-blkback:
allow module to be cleanly unloaded". This patch fixes the problem by
taking/releasing extra module references in xen_blkif_alloc/free()
respectively.
Signed-off-by: NPaul Durrant <pdurrant@amazon.com>
Reviewed-by: NRoger Pau Monné <roger.pau@citrix.com>
Signed-off-by: NJuergen Gross <jgross@suse.com>

Commit 5e666938 ("of/platform: Pause/resume sync state during init
and of_platform_populate()") paused/resumed sync state during init only
if Linux had parsed and populated a devicetree.

However, the check for that (of_have_populated_dt()) can change after
of_platform_default_populate_init() executes.  One example of this is
when devicetree unittests are enabled.  This causes an unmatched
pause/resume of sync state. To avoid this, just unconditionally
pause/resume sync state during init.

Fixes: 5e666938 ("of/platform: Pause/resume sync state during init and of_platform_populate()")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Reviewed-by: NFrank Rowand <frowand.list@gmail.com>
Signed-off-by: NRob Herring <robh@kernel.org>

Fix device memory flows so that only once there will be no live mmaped
VA to a given allocation the matching object will be destroyed.

This prevents a potential scenario that existing VA that was mmaped by
one process might still be used post its deallocation despite that it's
owned now by other process.

The above is achieved by integrating with IB core APIs to manage
mmap/munmap. Only once the refcount will become 0 the DM object and its
underlay area will be freed.

Fixes: 3b113a1e ("IB/mlx5: Support device memory type attribute")
Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
Link: https://lore.kernel.org/r/20191212100237.330654-3-leon@kernel.orgSigned-off-by: NDoug Ledford <dledford@redhat.com>

Introduce rdma_user_mmap_entry_insert_range() API to be used once the
required key for the given entry should be in a given range.
Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
Link: https://lore.kernel.org/r/20191212100237.330654-2-leon@kernel.orgSigned-off-by: NDoug Ledford <dledford@redhat.com>

Since 62240a88 ("PCI: rockchip: Drop storing driver private outbound
resource data), the offset calculation is wrong to access the register
number to program the IO outbound ATU.

Fix this by computing the ATU IO register number based on the number of MEM
registers, not the size of the IO region.

This causes 'synchronous external aborts' like the following:

  mwifiex_pcie 0000:01:00.0: enabling device (0000 -> 0002)
  mwifiex_pcie: PCI memory map Virt0: 00000000a573ad00 PCI memory map Virt2: 00000000783126c4
  Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
  Modules linked in: mwifiex_pcie(+) mwifiex uvcvideo cfg80211 atmel_mxt_ts videobuf2_vmalloc ...
  CPU: 2 PID: 269 Comm: systemd-udevd Not tainted 5.4.0+ #327
  Hardware name: Google Kevin (DT)
  pstate: 60000005 (nZCv daif -PAN -UAO)
  pc : mwifiex_register_dev+0x264/0x3f8 [mwifiex_pcie]
  lr : mwifiex_register_dev+0x150/0x3f8 [mwifiex_pcie]
  sp : ffff800012073860
  x29: ffff800012073860 x28: ffff8000100a2e28
  x27: ffff8000118b6210 x26: ffff800008f57458
  x25: ffff0000ecfda000 x24: 0000000000000001
  x23: ffff0000e9905080 x22: ffff800008f5d000
  x21: ffff0000eecea078 x20: ffff0000e9905080
  x19: ffff0000eecea000 x18: 0000000000000001
  x17: 0000000000000000 x16: 0000000000000000
  x15: ffffffffffffffff x14: ffff8000118998c8
  x13: ffff000000000000 x12: 0000000000000008
  x11: 0101010101010101 x10: ffff7f7fffff7fff
  x9 : 0000000000000000 x8 : ffff0000e3c24240
  x7 : 0000000000000000 x6 : ffff0000e3c24148
  x5 : ffff0000e3c24148 x4 : ffff0000e7975ec8
  x3 : 0000000000000001 x2 : 0000000000002b42
  x1 : ffff800012c00008 x0 : ffff0000e9905080
  Call trace:
   mwifiex_register_dev+0x264/0x3f8 [mwifiex_pcie]
   mwifiex_add_card+0x2f8/0x430 [mwifiex]
   mwifiex_pcie_probe+0x98/0x148 [mwifiex_pcie]
   pci_device_probe+0x110/0x1a8
   ...
  Code: a8c67bfd d65f03c0 f942ac01 91002021 (b9400021)
Suggested-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Fixes: 62240a88 ("PCI: rockchip: Drop storing driver private outbound resource data)
Link: https://lore.kernel.org/r/20191211093450.7481-1-enric.balletbo@collabora.comReported-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Reported-by: NVicente Bergas <vicencb@gmail.com>
Tested-by: NVicente Bergas <vicencb@gmail.com>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAndrew Murray <andrew.murray@arm.com>

It may fail to load guest driver in round 2 when using invalidate
semaphore for SRIOV. So it needs to avoid using invalidate semaphore
for SRIOV.
Signed-off-by: Nchangzhu <Changfeng.Zhu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It may fail to load guest driver in round 2 or cause Xstart problem
when using invalidate semaphore for SRIOV or picasso. So it needs avoid
using invalidate semaphore for SRIOV and picasso.
Signed-off-by: Nchangzhu <Changfeng.Zhu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There are two flow rule destinations: QP and packet. While users are
setting DROP packet rule, the QP should not be set as a destination.

Fixes: 3b3233fb ("IB/mlx5: Add flow counters binding support")
Signed-off-by: NMaor Gottlieb <maorg@mellanox.com>
Reviewed-by: NRaed Salem <raeds@mellanox.com>
Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
Link: https://lore.kernel.org/r/20191212091214.315005-4-leon@kernel.orgSigned-off-by: NDoug Ledford <dledford@redhat.com>