Commit Graph

982974 Commits

Author SHA1 Message Date
Stephen Boyd
3b25f33792
spi: spi-geni-qcom: Use the new method of gpio CS control
Let's set the 'use_gpio_descriptors' field so that we use the new way of
requesting the CS GPIOs in the core. This allows us to avoid having to
configure the CS pins in "output" mode with an 'output-enable' pinctrl
setting.

Cc: Akash Asthana <akashast@codeaurora.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20201204193540.3047030-4-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-09 16:52:10 +00:00
Stephen Boyd
7a5172b799
platform/chrome: cros_ec_spi: Drop bits_per_word assignment
This is already handed by default in spi_setup() if the bits_per_word is
0, so just drop it to shave off a line.

Cc: Simon Glass <sjg@chromium.org>
Cc: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20201204193540.3047030-3-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-09 16:52:09 +00:00
Stephen Boyd
74639cbf51
platform/chrome: cros_ec_spi: Don't overwrite spi::mode
There isn't any need to overwrite the mode here in the driver with what
has been detected by the firmware, such as DT or ACPI. In fact, if we
use the SPI CS gpio descriptor feature we will overwrite the mode with
SPI_MODE_0 where it already contains SPI_MODE_0 and more importantly
SPI_CS_HIGH. Clearing the SPI_CS_HIGH bit causes the CS line to toggle
when the device is probed when it shouldn't change, confusing the driver
and making it fail to probe. Drop the assignment and let the spi core
take care of it.

Fixes: a17d94f0b6 ("mfd: Add ChromeOS EC SPI driver")
Cc: Simon Glass <sjg@chromium.org>
Cc: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20201204193540.3047030-2-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-09 16:52:08 +00:00
Kai Vehmanen
ac6b7bd33a
ASoC: SOF: Intel: add SoundWire support for ADL-S
Expand SOF support for Alder Lake by adding ACPI machine tables
for ADL-S systems with SoundWire codecs. Modify kernel config
to choose SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE for these
platforms.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20201209153102.3028310-2-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-09 16:52:05 +00:00
Kai Vehmanen
4c8a4cab33
ASoC: Intel: common: add ACPI matching tables for Alder Lake
Initial support for ADL w/ RT711

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20201209153102.3028310-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-09 16:52:04 +00:00
Arnd Bergmann
c87b013f23 arm64: dts: ZynqMP DT changes for v5.11
- Wiring IPI communication channel with firmware driver
 - Taking GIC to main bus to have only one
 - Small fix in zynqmp.dtsi reported by dt_binding_check
 -----BEGIN PGP SIGNATURE-----
 
 iF0EABECAB0WIQQbPNTMvXmYlBPRwx7KSWXLKUoMIQUCX9DlAwAKCRDKSWXLKUoM
 ITJiAJ90LYMCutcZExL1FKJoPiJYsdYZqwCZAQ/q5gWgBny8HC5t5jxt84wN84Q=
 =wxe9
 -----END PGP SIGNATURE-----

Merge tag 'zynqmp-dt-for-v5.11' of https://github.com/Xilinx/linux-xlnx into arm/dt

arm64: dts: ZynqMP DT changes for v5.11

- Wiring IPI communication channel with firmware driver
- Taking GIC to main bus to have only one
- Small fix in zynqmp.dtsi reported by dt_binding_check

* tag 'zynqmp-dt-for-v5.11' of https://github.com/Xilinx/linux-xlnx:
  arm64: dts: zynqmp: Wire mailbox with zynqmp-power driver
  arm64: dts: zynqmp: Fix pcie ranges description
  arm64: zynqmp: Move gic node to axi bus

Link: https://lore.kernel.org/r/f460f6ac-d235-a33b-3d0f-ca904a43e687@monstr.eu
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:51:45 +01:00
Arnd Bergmann
419fd28627 ASPEED device tree updates for 5.11
- New machines
 
    * Bytedance G220A, an AST2500 BMC for an x86 server
    * Facebook Galaxy100, an AST2400 BMC for a network switch
    * IBM Rainier 4U, an AST2600 BMC for a PowerPC server
 
  - Reworking of Facebook device trees to use common dtsi
 
  - A 64MB flash layout used by the G220A
 
  - Misc updates to tiogapass, ethanolx, s2600wf, tacoma and rainier
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE+nHMAt9PCBDH63wBa3ZZB4FHcJ4FAl/EkHsACgkQa3ZZB4FH
 cJ7N3g/+OiAJonjZljHihLBQhBD2/RH8WR6OFZJZSnGAPmT4xdMBeOIjXVAjHpVX
 KyUZ2SNL69MAhBnkY029YDAdTa17i1PcaqVySpCbDgoJGIJYKFZ8zdi0Z35+tA4D
 oyqg5Vcz9B6ANGBhb87HhSia5xUuhcE1Il5gyNuLAfoDDRfT9SYx+iiumUc9mXev
 XQYcqvH+KHiPGs+5c9pouwqkAvoAQIRs6TGrLlhXsQRK8yWYrFWiBCPMNCGJVAf5
 dy7xkKBbv9178bo69v+5MTT7VW+S2gpiQPwPFYxana19qt1kEjwIb61ZuS+2cE6h
 K8rRnHOuNnTH/h4sjjtV2sb2ksuCpoYI2qER4kxkIrJI+RzuaPNH5puK4FI4khE5
 wr2eGCFH1+HxTV1sFzNw8cve4ZcfQnIS7lgTlH8MlK5au2UHjZSYq5FzxSxYjxCY
 FFndlZZDMjSVoJfsp+FQ5plg3QR9ZDarv+qsNbi0EfknUZN14Ck696reJqg1BgEo
 khwyfo9CElfTMpsiWlTioZECO7eHx1iC2DIE5nV7sk94NpzQRLPFZvblNylpZx/8
 GLFZWXvtiuXigoaFkNN3rW+v2TA+qAjpGMmxTrs+Bix1oW/7usKfd091LMbgadHa
 9TvibLl0SJeiFGkbzQQ2XN/40jUWIMtzG493D3tu1iEHaiq14/c=
 =dRJd
 -----END PGP SIGNATURE-----

Merge tag 'aspeed-5.11-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed into arm/dt

ASPEED device tree updates for 5.11

 - New machines

   * Bytedance G220A, an AST2500 BMC for an x86 server
   * Facebook Galaxy100, an AST2400 BMC for a network switch
   * IBM Rainier 4U, an AST2600 BMC for a PowerPC server

 - Reworking of Facebook device trees to use common dtsi

 - A 64MB flash layout used by the G220A

 - Misc updates to tiogapass, ethanolx, s2600wf, tacoma and rainier

* tag 'aspeed-5.11-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed: (25 commits)
  ARM: dts: aspeed: ast2600evb: Add MAC0
  ARM: dts: aspeed: rainier: Don't shout addresses
  ARM: dts: aspeed: rainier: Mark FSI SPI controllers as restricted
  ARM: dts: tacoma: Add reserved memory for ramoops
  ARM: dts: rainier: Add reserved memory for ramoops
  ARM: dts: tacoma: Fix node vs reg mismatch for flash memory
  ARM: dts: aspeed: rainier: Add 4U device-tree
  arm: dts: aspeed: tiogapass: Enable second MAC
  ARM: dts: aspeed: minipack: Fixup I2C tree
  ARM: dts: aspeed: wedge400: Fix FMC flash0 layout
  ARM: dts: aspeed: Add Facebook Galaxy100 (AST2400) BMC
  ARM: dts: aspeed: wedge100: Use common dtsi
  ARM: dts: aspeed: wedge40: Use common dtsi
  ARM: dts: aspeed: Common dtsi for Facebook AST2400 Network BMCs
  ARM: dts: aspeed: amd-ethanolx: Add GPIO line names
  ARM: dts: aspeed: amd-ethanolx: Enable devices for the iKVM functionality
  ARM: dts: aspeed: amd-ethanolx: Enable KCS channel 3
  ARM: dts: aspeed: tiogapass: Remove vuart
  ARM: dts: Fix label address for 64MiB OpenBMC flash layout
  ARM: dts: aspeed: g220a: Add some gpios
  ...

Link: https://lore.kernel.org/r/CACPK8Xfd7AmuEaUdFfYLu4ktcrpTnYUgwQSxUbC-McB02hvo_g@mail.gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:48:21 +01:00
Daniel Palmer
5919eec0f0 ARM: mstar: SMP support
This patch adds SMP support for MStar/Sigmastar chips that have a second core
like those in the infinity2m family.

So far only single and dual core chips have been found so this does
the bare minimum to boot the second core. From what I can tell not having
the "holding pen" code to handle multiple cores is fine if there is only
one core the will get booted. This might need to be reconsidered if chips
with more cores turn up.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20201201134330.3037007-11-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:45:40 +01:00
Daniel Palmer
ecaafac1eb ARM: mstar: Wire up smpctrl for SSD201/SSD202D
Add the specific compat string for the smpctrl registers to the
SSD201/SSD202D common dtsi.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20201201134330.3037007-10-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:45:40 +01:00
Daniel Palmer
570e471ce0 ARM: mstar: Add smp ctrl registers to infinity2m dtsi
Add the smpctrl registers to the infinity2m dtsi so that the
second CPU can be enabled on chips in this family.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20201201134330.3037007-9-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:45:40 +01:00
Daniel Palmer
418cb58b45 ARM: mstar: Add dts for Honestar ssd201htv2
Add a dts for the Honestar ssd201htv2 devkit.
This is for the board populated with a SSD202D.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20201201134330.3037007-8-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:45:40 +01:00
Daniel Palmer
dbbaf35d58 ARM: mstar: Add chip level dtsi for SSD202D
Add a chip level dtsi for the SigmaStar SSD202D

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20201201134330.3037007-7-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:45:40 +01:00
Daniel Palmer
572ef97bc7 ARM: mstar: Add common dtsi for SSD201/SSD202D
The SSD201 and SSD202D are basically the same chip with a different DDR die
packaged (64MB DDR2 or 128MB DDR3).

This patch adds a shared dtsi for the common parts of these chips like
gpio, pinctrl etc.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20201201134330.3037007-6-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:45:40 +01:00
Daniel Palmer
ba2290b1b7 ARM: mstar: Add infinity2m support
The infinity2m series of chips are like the other Mstar/Sigmastar
chips in that they have a Cortex A7 system with DDR memory integrated
in a single package.

The infinity2m chips are intended for recording the incoming streams
from IP cameras. So instead of video encoders they have video decoders,
instead of a camera interface they have display hardware and so on.

Aside from the above points the big difference about these chips is that
they include a second Cortex A7 core.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20201201134330.3037007-5-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:45:39 +01:00
Daniel Palmer
8c50a8b359 dt-bindings: mstar: Add Honestar SSD201_HT_V2 to mstar boards
The Honestar SSD201_HT_V2 is a full size devkit for the SigmaStar
SSD201 or SSD202D (they are pin compatible).

Currently only the SSD202D version is supported as that's the one
I have.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://linux-chenxing.org/infinity2/ssd201_ht_v2/
Link: https://lore.kernel.org/r/20201201134330.3037007-4-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:45:39 +01:00
Daniel Palmer
43181b5d80 dt-bindings: vendor-prefixes: Add honestar vendor prefix
Add prefix for Honestar Technologies Co., Ltd.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20201201134330.3037007-3-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:45:39 +01:00
Daniel Palmer
80e73332ee dt-bindings: mstar: Add binding details for mstar,smpctrl
This adds a YAML description of the smpctrl node needed by the
platform code for the MStar/SigmaStar Armv7 SoCs to boot secondary cpus.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20201201134330.3037007-2-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:45:39 +01:00
Oliver Hartkopp
323a391a22 can: isotp: isotp_setsockopt(): block setsockopt on bound sockets
The isotp socket can be widely configured in its behaviour regarding addressing
types, fill-ups, receive pattern tests and link layer length. Usually all
these settings need to be fixed before bind() and can not be changed
afterwards.

This patch adds a check to enforce the common usage pattern.

Fixes: e057dd3fc2 ("can: add ISO 15765-2:2016 transport protocol")
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Thomas Wagner <thwa1@web.de>
Link: https://lore.kernel.org/r/20201203140604.25488-2-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/r/20201204133508.742120-3-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-09 08:44:15 -08:00
Daniel Palmer
5b8a05b9e8 ARM: mstar: Fill in GPIO controller properties for infinity
Fill in the properties needed to use the GPIO controller
in the infinity and infinity3 chips.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201129110803.2461700-6-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:42:30 +01:00
Daniel Palmer
74530d6451 ARM: mstar: Add gpio controller to MStar base dtsi
The GPIO controller is at the same address in all of the
currently known chips so create a node for it in the base
dtsi.

Some extra properties are needed to actually use it so
disable it by default.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201129110803.2461700-5-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:42:29 +01:00
Alan Stern
52abca64fd scsi: block: Do not accept any requests while suspended
blk_queue_enter() accepts BLK_MQ_REQ_PM requests independent of the runtime
power management state. Now that SCSI domain validation no longer depends
on this behavior, modify the behavior of blk_queue_enter() as follows:

   - Do not accept any requests while suspended.

   - Only process power management requests while suspending or resuming.

Submitting BLK_MQ_REQ_PM requests to a device that is runtime suspended
causes runtime-suspended devices not to resume as they should. The request
which should cause a runtime resume instead gets issued directly, without
resuming the device first. Of course the device can't handle it properly,
the I/O fails, and the device remains suspended.

The problem is fixed by checking that the queue's runtime-PM status isn't
RPM_SUSPENDED before allowing a request to be issued, and queuing a
runtime-resume request if it is.  In particular, the inline
blk_pm_request_resume() routine is renamed blk_pm_resume_queue() and the
code is unified by merging the surrounding checks into the routine.  If the
queue isn't set up for runtime PM, or there currently is no restriction on
allowed requests, the request is allowed.  Likewise if the BLK_MQ_REQ_PM
flag is set and the status isn't RPM_SUSPENDED.  Otherwise a runtime resume
is queued and the request is blocked until conditions are more suitable.

[ bvanassche: modified commit message and removed Cc: stable because
  without the previous patches from this series this patch would break
  parallel SCSI domain validation + introduced queue_rpm_status() ]

Link: https://lore.kernel.org/r/20201209052951.16136-9-bvanassche@acm.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Can Guo <cang@codeaurora.org>
Cc: Stanley Chu <stanley.chu@mediatek.com>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reported-and-tested-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:41:42 -05:00
Bart Van Assche
a4d34da715 scsi: block: Remove RQF_PREEMPT and BLK_MQ_REQ_PREEMPT
Remove flag RQF_PREEMPT and BLK_MQ_REQ_PREEMPT since these are no longer
used by any kernel code.

Link: https://lore.kernel.org/r/20201209052951.16136-8-bvanassche@acm.org
Cc: Can Guo <cang@codeaurora.org>
Cc: Stanley Chu <stanley.chu@mediatek.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Martin Kepplinger <martin.kepplinger@puri.sm>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:41:42 -05:00
Bart Van Assche
e6044f714b scsi: core: Only process PM requests if rpm_status != RPM_ACTIVE
Instead of submitting all SCSI commands submitted with scsi_execute() to a
SCSI device if rpm_status != RPM_ACTIVE, only submit RQF_PM (power
management requests) if rpm_status != RPM_ACTIVE. This patch makes the SCSI
core handle the runtime power management status (rpm_status) as it should
be handled.

Link: https://lore.kernel.org/r/20201209052951.16136-7-bvanassche@acm.org
Cc: Can Guo <cang@codeaurora.org>
Cc: Stanley Chu <stanley.chu@mediatek.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Martin Kepplinger <martin.kepplinger@puri.sm>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:41:42 -05:00
Bart Van Assche
cfefd9f824 scsi: scsi_transport_spi: Set RQF_PM for domain validation commands
Disable runtime power management during domain validation. Since a later
patch removes RQF_PREEMPT, set RQF_PM for domain validation commands such
that these are executed in the quiesced SCSI device state.

Link: https://lore.kernel.org/r/20201209052951.16136-6-bvanassche@acm.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Woody Suwalski <terraluna977@gmail.com>
Cc: Can Guo <cang@codeaurora.org>
Cc: Stanley Chu <stanley.chu@mediatek.com>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Stan Johnson <userm57@yahoo.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:41:42 -05:00
Bart Van Assche
5ae65383fc scsi: ide: Mark power management requests with RQF_PM instead of RQF_PREEMPT
This is another step that prepares for the removal of RQF_PREEMPT.

Link: https://lore.kernel.org/r/20201209052951.16136-5-bvanassche@acm.org
Cc: David S. Miller <davem@davemloft.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Can Guo <cang@codeaurora.org>
Cc: Stanley Chu <stanley.chu@mediatek.com>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:41:42 -05:00
Bart Van Assche
96d86e6a80 scsi: ide: Do not set the RQF_PREEMPT flag for sense requests
RQF_PREEMPT is used for two different purposes in the legacy IDE code:

 1. To mark power management requests.

 2. To mark requests that should preempt another request. An (old)
    explanation of that feature is as follows: "The IDE driver in the Linux
    kernel normally uses a series of busywait delays during its
    initialization. When the driver executes these busywaits, the kernel
    does nothing for the duration of the wait. The time spent in these
    waits could be used for other initialization activities, if they could
    be run concurrently with these waits.

    More specifically, busywait-style delays such as udelay() in module
    init functions inhibit kernel preemption because the Big Kernel Lock is
    held, while yielding APIs such as schedule_timeout() allow
    preemption. This is true because the kernel handles the BKL specially
    and releases and reacquires it across reschedules allowed by the
    current thread.

    This IDE-preempt specification requires that the driver eliminate these
    busywaits and replace them with a mechanism that allows other work to
    proceed while the IDE driver is initializing."

Since I haven't found an implementation of (2), do not set the PREEMPT flag
for sense requests. This patch causes sense requests to be postponed while
a drive is suspended instead of being submitted to ide_queue_rq().

If it would ever be necessary to restore the IDE PREEMPT functionality,
that can be done by introducing a new flag in struct ide_request.

Link: https://lore.kernel.org/r/20201209052951.16136-4-bvanassche@acm.org
Cc: David S. Miller <davem@davemloft.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Can Guo <cang@codeaurora.org>
Cc: Stanley Chu <stanley.chu@mediatek.com>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:41:42 -05:00
Bart Van Assche
0854bcdcde scsi: block: Introduce BLK_MQ_REQ_PM
Introduce the BLK_MQ_REQ_PM flag. This flag makes the request allocation
functions set RQF_PM. This is the first step towards removing
BLK_MQ_REQ_PREEMPT.

Link: https://lore.kernel.org/r/20201209052951.16136-3-bvanassche@acm.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Stanley Chu <stanley.chu@mediatek.com>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Can Guo <cang@codeaurora.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:41:41 -05:00
Bart Van Assche
fa4d0f1992 scsi: block: Fix a race in the runtime power management code
With the current implementation the following race can happen:

 * blk_pre_runtime_suspend() calls blk_freeze_queue_start() and
   blk_mq_unfreeze_queue().

 * blk_queue_enter() calls blk_queue_pm_only() and that function returns
   true.

 * blk_queue_enter() calls blk_pm_request_resume() and that function does
   not call pm_request_resume() because the queue runtime status is
   RPM_ACTIVE.

 * blk_pre_runtime_suspend() changes the queue status into RPM_SUSPENDING.

Fix this race by changing the queue runtime status into RPM_SUSPENDING
before switching q_usage_counter to atomic mode.

Link: https://lore.kernel.org/r/20201209052951.16136-2-bvanassche@acm.org
Fixes: 986d413b7c ("blk-mq: Enable support for runtime power management")
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Stanley Chu <stanley.chu@mediatek.com>
Co-developed-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:41:41 -05:00
Kevin Hilman
dcb11100cd arm64: Kconfig: meson: drop pinctrl
Don't automatically select pinctrl drivers, leave it up to defaults in
drivers/pinctrl/meson, which default to built-in, but are also now
optionally configurable as modules as of
commit 9c65441ec8 ("pinctrl/meson: enable building as modules")

Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20201207230156.10198-1-khilman@baylibre.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-12-09 17:36:46 +01:00
Adrian Hunter
dd78bdb6f8 scsi: ufs-pci: Enable UFSHCD_CAP_RPM_AUTOSUSPEND for Intel controllers
Enable runtime PM auto-suspend by default for Intel host controllers.

Link: https://lore.kernel.org/r/20201207083120.26732-5-adrian.hunter@intel.com
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:20 -05:00
Adrian Hunter
044d5bda71 scsi: ufs-pci: Fix recovery from hibernate exit errors for Intel controllers
Intel controllers can end up in an unrecoverable state after a hibernate
exit error unless a full reset and restore is done before anything else.
Force that to happen.

Link: https://lore.kernel.org/r/20201207083120.26732-4-adrian.hunter@intel.com
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:20 -05:00
Adrian Hunter
af423534d2 scsi: ufs-pci: Ensure UFS device is in PowerDown mode for suspend-to-disk ->poweroff()
The expectation for suspend-to-disk is that devices will be powered-off, so
the UFS device should be put in PowerDown mode. If spm_lvl is not 5, then
that will not happen. Change the pm callbacks to force spm_lvl 5 for
suspend-to-disk poweroff.

Link: https://lore.kernel.org/r/20201207083120.26732-3-adrian.hunter@intel.com
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:20 -05:00
Adrian Hunter
c763729a10 scsi: ufs-pci: Fix restore from S4 for Intel controllers
Currently, ufshcd-pci is the only UFS driver with support for
suspend-to-disk PM callbacks (i.e. freeze/thaw/restore/poweroff). These
callbacks are set by the macro SET_SYSTEM_SLEEP_PM_OPS to the same
functions as system suspend/resume. That will work with spm_lvl 5 because
spm_lvl 5 will result in a full restore for the ->restore() callback.  In
the absence of a full restore, the host controller registers will have
values set up by the restore kernel (the kernel that boots and loads the
restore image) which are not necessarily the same. However it turns out,
the only registers that sometimes need restore are the base address
registers. This has gone un-noticed because, depending on IOMMU settings,
the kernel can end up allocating the same addresses every time.

For Intel controllers, an spm_lvl other than 5 can be used, so to support
S4 (suspend-to-disk) with spm_lvl other than 5, restore the base address
registers.

Link: https://lore.kernel.org/r/20201207083120.26732-2-adrian.hunter@intel.com
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:20 -05:00
Stanley Chu
b3f3d31a52 scsi: ufs-mediatek: Keep VCC always-on for specific devices
For some devices which need extra delay after VCC power down, VCC shall be
kept always-on in some MediaTek UFS platforms to ensure the stability of
such devices because the extra delay may not be enough in those platforms.

Link: https://lore.kernel.org/r/20201207054955.24366-3-stanley.chu@mediatek.com
Reviewed-by: Andy Teng <andy.teng@mediatek.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:20 -05:00
Suganath Prabu S
be1b500212 scsi: mpt3sas: Update driver version to 36.100.00.00
Update driver version to 36.100.00.00

Link: https://lore.kernel.org/r/20201126094311.8686-9-suganath-prabu.subramani@broadcom.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:19 -05:00
Stanley Chu
f8162ac70e scsi: ufs: Allow regulators being always-on
Introduce a flag "always_on" in struct ufs_vreg to allow vendors to keep
the regulator always-on.

Link: https://lore.kernel.org/r/20201207054955.24366-2-stanley.chu@mediatek.com
Reviewed-by: Andy Teng <andy.teng@mediatek.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:19 -05:00
Suganath Prabu S
9b271c6912 scsi: mpt3sas: Handle trigger page after firmware update
If a firmware update adds support for the trigger pages, then the driver
should handle this by writing the existing trigger data from the driver's
internal data structure to the corresponding trigger pages in NVRAM.

Also handle the case where the trigger page capability is no longer present
after a firmware downgrade.

Link: https://lore.kernel.org/r/20201126094311.8686-8-suganath-prabu.subramani@broadcom.com
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:19 -05:00
Randall Huang
1918651f2d scsi: ufs: Clear UAC for RPMB after ufshcd resets
If RPMB is not provisioned, we may see RPMB failure after UFS
suspend/resume.  Inject request_sense to clear uac in ufshcd reset flow.

Link: https://lore.kernel.org/r/20201201041402.3860525-1-jaegeuk@kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Randall Huang <huangrandall@google.com>
Signed-off-by: Leo Liou <leoliou@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:19 -05:00
Suganath Prabu S
0e17a87c59 scsi: mpt3sas: Add persistent MPI trigger page
This page is used to store information about MPI (IOC Status & LogInfo)
triggers.

 Driver Persistent Trigger Page-4 format:
 -------------------------------------------------------
 | 31       24 23           16 15         8 7          0|  Byte
 -------------------------------------------------------
 | PageType   | PageNumber    | Reserved  | PageVersion |  0x00
 --------------------------------------------------------
 | Reserved   | ExtPageType   |      ExtPageLength      |  0x04
 --------------------------------------------------------
 |          Reserved          | NumMpiTriggerEntries    |  0x08
 --------------------------------------------------------
 |             MPITriggerEntry[0]                       |  0x0C
 --------------------------------------------------------
 |               …                                      |
 --------------------------------------------------------
 |            MPITriggerEntry[19]                       |  0xA4
 --------------------------------------------------------

NumMpiTriggerEntries:

This field indicates number of MPI (IOC Status & LogInfo) trigger entries
stored in this page. Currently driver is supporting a maximum of 20-MPI
trigger entries.

MPITriggerEntry:

 -----------------------------------------------------
 | 31                    16 15                     0 |
 -----------------------------------------------------
 |        Reserved         |      IOCStatus          |
 -----------------------------------------------------
 |                   IOCLogInfo                      |
 -----------------------------------------------------

IOCStatus  => Status value from the IOC
IOCLogInfo => Specific value that supplements the IOCStatus.

Link: https://lore.kernel.org/r/20201126094311.8686-7-suganath-prabu.subramani@broadcom.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:19 -05:00
Bean Huo
1fa0570002 scsi: ufs: Fix wrong print message in dev_err()
Change dev_err() print message from "dme-reset" to "dme_enable" in function
ufshcd_dme_enable().

Link: https://lore.kernel.org/r/20201207190137.6858-3-huobean@gmail.com
Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:19 -05:00
Suganath Prabu S
2a5c3a35c1 scsi: mpt3sas: Add persistent SCSI sense trigger page
Trigger Page3 is used to store information about SCSI Sense triggers:

 Persistent Trigger Page-3
 ------------------------------------------------------------------
 | 31         24 23            16 15              8 7            0|    Byte
 ------------------------------------------------------------------
 | PageType      | PageNumber     | Reserved       | PageVersion  |    0x00
 ------------------------------------------------------------------
 | Reserved      | ExtPageType    |          ExtPageLen           |    0x04
 ------------------------------------------------------------------
 | Reserved      | NumScsiSense   |         TriggerEntries        |    0x08
 ------------------------------------------------------------------
 |               ScsiSenseTriggerEntry[0]                         |    0x0C
 ------------------------------------------------------------------
 |                    …        …                                  |
 ------------------------------------------------------------------
 |               ScsiSenseTriggerEntry[19]                        |    0x58
 ------------------------------------------------------------------

NumScsiSenseTriggerEntries:

This field indicates number of SCSI Sense trigger entries stored in this
page. Currently driver is supporting a maximum of 20-SCSI Sense trigger
entries.

ScsiSenseTriggerEntry:

 -----------------------------------------------
 | 31      24 23       16 15       8 7       0 |
 -----------------------------------------------
 | Reserved   | SenseKey  |    ASC   |   ASCQ  |
 -----------------------------------------------

 ASCQ     => Additional Sense Code Qualifier
 ASC      => Additional Sense Code
 SenseKey => Sense Key values

 ASCQ     => Additional Sense Code Qualifier
 ASC      => Additional Sense Code
 SenseKey => Sense Key values

Link: https://lore.kernel.org/r/20201126094311.8686-6-suganath-prabu.subramani@broadcom.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:19 -05:00
Bean Huo
44fd9fb599 scsi: ufs: Remove unused macro definition POWER_DESC_MAX_SIZE
POWER_DESC_MAX_SIZE is unused, remove it.

Link: https://lore.kernel.org/r/20201207190137.6858-2-huobean@gmail.com
Acked-by: Avri Altman <avri.altman@wdc.com>
Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:19 -05:00
Suganath Prabu S
71b3fb8fe6 scsi: mpt3sas: Add persistent Event trigger page
Trigger Page2 is used to store information about Event triggers:

  31     24 23        16 15      8 7         0   Byte
 -----------------------------------------------
 |PageType  |PageNumber  |Reserved |PageVersion| 0x00
 -----------------------------------------------
 |Reserved  |ExtPageType |   ExtPageLength     | 0x04
 -----------------------------------------------
 |     Reserved          | NumMPIEventTriggers | 0x08
 -----------------------------------------------
 |                 MPIEventTriggerEntries      | 0x0C
 |                                             | 0xFC
 -----------------------------------------------

Number of MPI Event Trigger Entries currently stored in this page.  If this
is set to zero, there are no valid MPI-Event-Trigger entries available in
this page.

MPIEventTriggerEntry:

 - MPIEventCode [15:00]
   MPI Event code specified in MPI-Spec

 - MPIEventCodeSpecific [16:31]
   For Event Code “MPI2_EVENT_LOG_ENTRY_ADDED (0x0021)”,
   this field specifies the Log-Entry-Qualifier.
   For all other Event Codes, this field is reserved and not used

Maximum of 20-event trigger entries can be stored in this page.

Link: https://lore.kernel.org/r/20201126094311.8686-5-suganath-prabu.subramani@broadcom.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:19 -05:00
Suganath Prabu S
bb855f2a5d scsi: mpt3sas: Add persistent Master trigger page
Trigger Page 1 is used to store information about Master triggers.  Below
are the Master trigger conditions:

  Bit[3]  Trigger condition for Device Removal event
  Bit[2]  Trigger condition for TM command issued by driver
  Bit[1]  Trigger condition for Adapter reset issued by driver
  Bit[0]  Trigger condition for IOC Fault state

During driver load, if Master trigger type bit is enabled in the Persistent
Trigger Page0, then read the Persistent Trigger Page1 and update the IOC
instance's diag_trigger_master.MasterData with Persistent Trigger Page1's
MasterTriggerFlags.

Link: https://lore.kernel.org/r/20201126094311.8686-4-suganath-prabu.subramani@broadcom.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:19 -05:00
Suganath Prabu S
aec93e8e23 scsi: mpt3sas: Add persistent trigger pages support
The user can set trigger values in order to collect the IOC's host trace
buffer automatically upon detecting certain conditions. However, the
trigger values that the user sets are not persistent across system reboot
or reload of the driver.

In order to make the user trigger settings persistent, these trigger values
need to be saved in the IOC's NVRAM pages:

 - Driver Persistent Trigger Page 0:
     This page is used to store list of trigger types that are enabled

 - Driver Persistent Trigger Page 1:
     This page stores the list of Master triggers that are enabled

 - Driver Persistent Trigger Page 2:
     This page stores the list of MPI Event Triggers that are enabled

 - Driver Persistent Trigger Page 3:
     This page stores the list of SCSI Sense Triggers that are enabled

 - Driver Persistent Trigger Page 4:
     This page stores the list of IOCStatus-LogInfo Triggers that are
     enabled.

Whenever user configures triggers, the driver persists the values in the
corresponding trigger pages. When the driver is subsequently reloaded, the
driver reads the values from the trigger pages and configures the triggers
accordingly.

During firmware upload operation, if the newer firmware supports the
trigger page feature, then driver persists the configured diag trigger
values to NVRAM.

Link: https://lore.kernel.org/r/20201126094311.8686-3-suganath-prabu.subramani@broadcom.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:18 -05:00
Suganath Prabu S
f98790c003 scsi: mpt3sas: Sync time periodically between driver and firmware
The controller time currently gets updated with host time during driver
load or when a controller reset is issued. I.e. when host issues the
IOCInit request message to the HBA firmware. This IOCInit message has a
field named 'TimeStamp' with which the host updates the controller time.

Sometimes controller time drifts with respect to the host and it is
difficult to correlate host logs with controller logs. Issuing a controller
reset to sync the time would impact in-flight I/O and is not a viable
option.

Instead the driver now sends an IO_UNIT_CONTROL Request to sync the time
periodically. This is done from the watchdog thread which gets invoked
every second.

The time synchronization interval is specified in the 'TimeSyncInterval'
field in Manufacturing Page11 by the controller:

    TimeSyncInterval - 8 bits
	bits  0-6: Time stamp Synchronization interval value
	bit	7: Time stamp Synchronization interval unit,
		   (if this bit is one then Timestamp Synchronization
		   interval value is specified in terms of hours else
		   Timestamp Synchronization interval value is
		   specified in terms of minutes).

The driver keeps track of the timer using IOC's timestamp_update_count
field. This field value gets incremented whenever the watchdog thread gets
invoked. And whenever this field value is greater than or equal to the Time
Stamp Synchronization interval value, the driver sends the IO_UNIT_CONTROL
Request message to controller to update the time and then it resets the
timestamp_update_count field to zero.

Link: https://lore.kernel.org/r/20201126094311.8686-2-suganath-prabu.subramani@broadcom.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:18 -05:00
Nilesh Javali
afc516dcfe scsi: qla2xxx: Update version to 10.02.00.104-k
Link: https://lore.kernel.org/r/20201202132312.19966-16-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:18 -05:00
Arun Easi
abd9cae9bb scsi: qla2xxx: Fix device loss on 4G and older HBAs
Due to a bug in the older scan logic, when a once lost device re-appeared,
it was not discovered. Fix this by resetting login_retry counter upon
device discovery.

This is applicable only for 4G and older HBAs.

Link: https://lore.kernel.org/r/20201202132312.19966-15-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Arun Easi <aeasi@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:18 -05:00
Saurav Kashyap
707531bc26 scsi: qla2xxx: If fcport is undergoing deletion complete I/O with retry
Driver unload with I/Os in flight causes server to crash.  Complete I/O
with DID_IMM_RETRY if fcport undergoing deletion.

CPU: 44 PID: 35008 Comm: qla2xxx_4_dpc Kdump: loaded Tainted: G
OE  X   5.3.18-22-default #1 SLE15-SP2 (unreleased)
Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 07/16/2020
RIP: 0010:dma_direct_unmap_sg+0x24/0x60
Code: 4c 8b 04 24 eb b9 0f 1f 44 00 00 85 d2 7e 4e 41 57
      4d 89 c7 41 56 41 89 ce 41 55 49 89 fd 41 54 41 89 d4 55 31 ed 53 48 89
      f3 <8b> 53 18 48 8b 73 10 4d 89 f8 44 89 f1 4c 89 ef 83 c5 01 e8 44 ff
RSP: 0018:ffffc0c661037d88 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000002
RDX: 000000000000001d RSI: 0000000000000000 RDI: ffff9a51ee53b0b0
RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9a51ee53b0b0
R10: ffffc0c646463dc8 R11: ffff9a4a067087c8 R12: 000000000000001d
R13: ffff9a51ee53b0b0 R14: 0000000000000002 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff9a523f800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000043740a004 CR4: 00000000007606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
qla2xxx_qpair_sp_free_dma+0x20d/0x3c0 [qla2xxx]
qla2xxx_qpair_sp_compl+0x35/0x90 [qla2xxx]
__qla2x00_abort_all_cmds+0x180/0x390 [qla2xxx]
? qla24xx_process_purex_list+0x100/0x100 [qla2xxx]
qla2x00_abort_all_cmds+0x5e/0x80 [qla2xxx]
qla2x00_do_dpc+0x317/0xa30 [qla2xxx]
kthread+0x10d/0x130
? kthread_park+0xa0/0xa0
ret_from_fork+0x35/0x40

Link: https://lore.kernel.org/r/20201202132312.19966-14-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:18 -05:00
Saurav Kashyap
0a6f4d762c scsi: qla2xxx: Fix the call trace for flush workqueue
The call trace was because workqueue was allocated without any flags, added
WQ_MEM_RECLAIM as flag when allocating.

kernel: workqueue: WQ_MEM_RECLAIM
kblockd:blk_mq_run_work_fn is flushing !WQ_MEM_RECLAIM qla2xxx_wq:0x0
kernel: WARNING: CPU: 0 PID: 2475 at
kernel/workqueue.c:2593 check_flush_dependency+0x110/0x130
kernel: CPU: 0 PID: 2475 Comm: kworker/0:1H Kdump:
loaded Tainted: G           OE    --------- -  - 4.18.0-193.el8.x86_64 #1
kernel: Hardware name: HPE ProLiant XL170r Gen10/ProLiant XL170r Gen10, BIOS U38 05/21/2019
kernel: Workqueue: kblockd blk_mq_run_work_fn
kernel: RIP: 0010:check_flush_dependency+0x110/0x130
kernel: Code: ff ff 48 8b 50 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 c7 00 1e e9
	95 c6 05 dc 9a 2f 01 01 e8 1a 42 fe ff <0f> 0b e9 0a ff ff ff 80 3d ca 9a 2f 01 0 0 75 95 e9 41 ff ff ff 90
kernel: RSP: 0018:ffffa40f48b2baf8 EFLAGS: 00010282
kernel: RAX: 0000000000000000 RBX: ffff946795282600 RCX: 0000000000000000
kernel: RDX: 000000000000005f RSI: ffffffff96a1af7f RDI: 0000000000000246
kernel: RBP: 0000000000000000 R08: ffffffff96a1af20 R09: 0000000000029480
kernel: R10: 00080c89bb3e7462 R11: 00000000000009ab R12: ffff946773628000
kernel: R13: 0000000000000282 R14: 0000000000000246 R15: ffffa40f48b2bb40
kernel: FS: 	0000000000000000(0000) 	GS:ffff94679fa00000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 00005570c4b60110 CR3: 000000029140a005 CR4: 00000000007606f0
kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
kernel: PKRU: 55555554
kernel: Call Trace:
kernel: flush_workqueue+0x13a/0x440
kernel: qla2x00_wait_for_sess_deletion+0x1d6/0x200 [qla2xxx]
kernel: ? finish_wait+0x80/0x80
kernel: qla2xxx_disable_port+0x2b/0x30 [qla2xxx]
kernel: qla2x00_process_vendor_specific+0x1dc9/0x2d20 [qla2xxx]
kernel: ? blk_rq_map_sg+0x195/0x570
kernel: qla24xx_bsg_request+0x1a3/0xf90 [qla2xxx]

Link: https://lore.kernel.org/r/20201202132312.19966-13-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-12-09 11:34:18 -05:00