| Age | Commit message (Collapse) | Author |
|---|
|
These were just some minor typos that have crept in recently and are
easily fixed.
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20201127104630.1839171-1-thierry.reding@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Device drivers usually depend on the fact that the devices that they
control are suspended in the same order that they were probed in. In
most cases this is already guaranteed via deferred probe.
However, there's one case where this can still break: if a device is
instantiated before a dependency (for example if it appears before the
dependency in device tree) but gets probed only after the dependency is
probed. Instantiation order would cause the dependency to get probed
later, in which case probe of the original device would be deferred and
the suspend/resume queue would get reordered properly. However, if the
dependency is provided by a built-in driver and the device depending on
that driver is controlled by a loadable module, which may only get
loaded after the root filesystem has become available, we can be faced
with a situation where the probe order ends up being different from the
suspend/resume order.
One example where this happens is on Tegra186, where the ACONNECT is
listed very early in device tree (sorted by unit-address) and depends on
BPMP (listed very late because it has no unit-address) for power domains
and clocks/resets. If the ACONNECT driver is built-in, there is no
problem because it will be probed before BPMP, causing a probe deferral
and that in turn reorders the suspend/resume queue. However, if built as
a module, it will end up being probed after BPMP, and therefore not
result in a probe deferral, and therefore the suspend/resume queue will
stay in the instantiation order. This in turn causes problems because
ACONNECT will be resumed before BPMP, which will result in a hang
because the ACONNECT's power domain cannot be powered on as long as the
BPMP is still suspended.
Fix this by always reordering devices on successful probe. This ensures
that the suspend/resume queue is always in probe order and hence meets
the natural expectations of drivers vs. their dependencies.
Reported-by: Jonathan Hunter <jonathanh@nvidia.com>
Acked-by: Rafael. J. Wysocki <rafael@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20201203175756.1405564-1-thierry.reding@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The struct device input to add_links() is not used for anything. So
delete it.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-18-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The current implementation of fw_devlink is very inefficient because it
tries to get away without creating fwnode links in the name of saving
memory usage. Past attempts to optimize runtime at the cost of memory
usage were blocked with request for data showing that the optimization
made significant improvement for real world scenarios.
We have those scenarios now. There have been several reports of boot
time increase in the order of seconds in this thread [1]. Several OEMs
and SoC manufacturers have also privately reported significant
(350-400ms) increase in boot time due to all the parsing done by
fw_devlink.
So this patch uses all the setup done by the previous patches in this
series to refactor fw_devlink to be more efficient. Most of the code has
been moved out of firmware specific (DT mostly) code into driver core.
This brings the following benefits:
- Instead of parsing the device tree multiple times during bootup,
fw_devlink parses each fwnode node/property only once and creates
fwnode links. The rest of the fw_devlink code then just looks at these
fwnode links to do rest of the work.
- Makes it much easier to debug probe issue due to fw_devlink in the
future. fw_devlink=on blocks the probing of devices if they depend on
a device that hasn't been added yet. With this refactor, it'll be very
easy to tell what that device is because we now have a reference to
the fwnode of the device.
- Much easier to add fw_devlink support to ACPI and other firmware
types. A refactor to move the common bits from DT specific code to
driver core was in my TODO list as a prerequisite to adding ACPI
support to fw_devlink. This series gets that done.
[1] - https://lore.kernel.org/linux-omap/ea02f57e-871d-cd16-4418-c1da4bbc4696@ti.com/
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-17-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The semantics of add_links() has changed from creating device link
between devices to creating fwnode links between fwnodes. So, update the
implementation of add_links() to match the new semantics.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-16-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The semantics of add_links() has changed from creating device link
between devices to creating fwnode links between fwnodes. So, update the
implementation of add_links() to match the new semantics.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-15-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
To check if a device is still waiting for its supplier devices to be
added, we used to check if the devices is in a global
waiting_for_suppliers list. Since the global list will be deleted in
subsequent patches, this patch stops using this check.
Instead, this patch uses a more device specific check. It checks if the
device's fwnode has any fwnode links that haven't been converted to
device links yet.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-14-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This function is a wrapper around fwnode_operations.add_links().
This function parses each node in a fwnode tree and create fwnode links
for each of those nodes. The information for creating the fwnode links
(the supplier and consumer fwnode) is obtained by parsing the properties
in each of the fwnodes.
This function also ensures that no fwnode is parsed more than once by
marking the fwnodes as parsed.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-13-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Change the meaning of fwnode_operations.add_links() to just create
fwnode links by parsing the properties of a given fwnode.
This patch doesn't actually make any code changes. To keeps things more
digestable, the actual functional changes come in later patches in this
series.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-12-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add fwnode_is_ancestor_of() helper function to check if a fwnode is an
ancestor of another fwnode.
Add fwnode_get_next_parent_dev() helper function that take as input a
fwnode and finds the closest ancestor fwnode that has a corresponding
struct device and returns that struct device.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-11-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
SYNC_STATE_ONLY device links only affect the behavior of sync_state()
callbacks. Specifically, they prevent sync_state() only callbacks from
being called on a device if one or more of its consumers haven't probed.
So, creating a SYNC_STATE_ONLY device link from an already probed
consumer is useless. So, don't allow creating such device links.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-10-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add support for creating supplier-consumer links between fwnodes. It is
intended for internal use the driver core and generic firmware support
code (eg. Device Tree, ACPI), so it is simple by design and the API
provided is limited.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-9-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
There are multiple locations in the kernel where a struct fwnode_handle
is initialized. Add fwnode_init() so that we have one way of
initializing a fwnode_handle.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-8-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 716a7a25969003d82ab738179c3f1068a120ed11.
The fw_devlink_pause/resume() APIs added by the commit being reverted
were a first cut attempt at optimizing boot time. But these APIs don't
fully solve the problem and are very fragile (can only be used for the
top level devices being added). This series replaces them with a much
better optimization that works for all device additions and also has the
benefit of reducing the complexity of the firmware (DT, EFI) specific
code and abstracting out common code to driver core.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-7-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 93d2e4322aa74c1ad1e8c2160608eb9a960d69ff.
The fw_devlink_pause/resume() optimization attempt is getting replaced
with a much more robust optimization by the end of this series. So, stop
using those APIs.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-6-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit fefcfc968723caf93318613a08e1f3ad07a6154f.
The reverted commit is fixing commit 716a7a259690 ("driver core:
fw_devlink: Add support for batching fwnode parsing"). Since the
original commit will be reverted, the fix can be reverted too.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-5-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
thread"
This reverts commit cec72f3efc6272420c2c2c699607f03d09b93e41.
Commit cec72f3efc62 ("driver core: Don't do deferred probe in parallel
with kernel_init thread") was fixing a commit 716a7a259690 ("driver
core: fw_devlink: Add support for batching fwnode parsing"). Since the
commit being fixed itself is going to be reverted, the fix can also be
reverted.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-4-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit ec7bd78498f29680f536451fbdf9464e851273ed.
This field rename was done to reuse defer_syc list head for multiple
lists. That's not needed anymore and this list head will only be used
for defer sync. So revert this patch to avoid conflicts with the other
reverts coming after this.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-3-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 2451e746478a6a6e981cfa66b62b791ca93b90c8.
fw_devlink_pause/resume() was an incomplete attempt at boot time
optimization. That's going to get replaced by a much better optimization
at the end of the series. Since fw_devlink_pause/resume() is going away,
changes made for that can also go away.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20201121020232.908850-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The device_links_purge() function (called from device_del()) tries to
remove the links.needs_suppliers list entry, but it's using
list_del(), hence it doesn't initialize after the removal. This is OK
for normal cases where device_del() is called via device_destroy().
However, it's not guaranteed that the device object will be really
deleted soon after device_del(). In a minor case like HD-audio codec
reconfiguration that re-initializes the device after device_del(), it
may lead to a crash by the corrupted list entry.
As a simple fix, replace list_del() with list_del_init() in order to
make the list intact after the device_del() call.
Fixes: e2ae9bcc4aaa ("driver core: Add support for linking devices during device addition")
Cc: <stable@vger.kernel.org>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20201208190326.27531-1-tiwai@suse.de
Cc: Saravana Kannan <saravanak@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
* arm64/for-next/fixes: (26 commits)
arm64: mte: fix prctl(PR_GET_TAGGED_ADDR_CTRL) if TCF0=NONE
arm64: mte: Fix typo in macro definition
arm64: entry: fix EL1 debug transitions
arm64: entry: fix NMI {user, kernel}->kernel transitions
arm64: entry: fix non-NMI kernel<->kernel transitions
arm64: ptrace: prepare for EL1 irq/rcu tracking
arm64: entry: fix non-NMI user<->kernel transitions
arm64: entry: move el1 irq/nmi logic to C
arm64: entry: prepare ret_to_user for function call
arm64: entry: move enter_from_user_mode to entry-common.c
arm64: entry: mark entry code as noinstr
arm64: mark idle code as noinstr
arm64: syscall: exit userspace before unmasking exceptions
arm64: pgtable: Ensure dirty bit is preserved across pte_wrprotect()
arm64: pgtable: Fix pte_accessible()
ACPI/IORT: Fix doc warnings in iort.c
arm64/fpsimd: add <asm/insn.h> to <asm/kprobes.h> to fix fpsimd build
arm64: cpu_errata: Apply Erratum 845719 to KRYO2XX Silver
arm64: proton-pack: Add KRYO2XX silver CPUs to spectre-v2 safe-list
arm64: kpti: Add KRYO2XX gold/silver CPU cores to kpti safelist
...
# Conflicts:
# arch/arm64/include/asm/exception.h
# arch/arm64/kernel/sdei.c
|
|
* arm64/for-next/perf:
perf/imx_ddr: Add system PMU identifier for userspace
bindings: perf: imx-ddr: add compatible string
arm64: Fix build failure when HARDLOCKUP_DETECTOR_PERF is enabled
arm64: Enable perf events based hard lockup detector
perf/imx_ddr: Add stop event counters support for i.MX8MP
perf/smmuv3: Support sysfs identifier file
drivers/perf: hisi: Add identifier sysfs file
perf: remove duplicate check on fwnode
driver/perf: Add PMU driver for the ARM DMC-620 memory controller
|
|
* for-next/uaccess:
: uaccess routines clean-up and set_fs() removal
arm64: mark __system_matches_cap as __maybe_unused
arm64: uaccess: remove vestigal UAO support
arm64: uaccess: remove redundant PAN toggling
arm64: uaccess: remove addr_limit_user_check()
arm64: uaccess: remove set_fs()
arm64: uaccess cleanup macro naming
arm64: uaccess: split user/kernel routines
arm64: uaccess: refactor __{get,put}_user
arm64: uaccess: simplify __copy_user_flushcache()
arm64: uaccess: rename privileged uaccess routines
arm64: sdei: explicitly simulate PAN/UAO entry
arm64: sdei: move uaccess logic to arch/arm64/
arm64: head.S: always initialize PSTATE
arm64: head.S: cleanup SCTLR_ELx initialization
arm64: head.S: rename el2_setup -> init_kernel_el
arm64: add C wrappers for SET_PSTATE_*()
arm64: ensure ERET from kthread is illegal
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull iommu fix from Will Deacon:
"Fix interrupt table length definition for AMD IOMMU.
It's actually a fix for a fix, where the size of the interrupt
remapping table was increased but a related constant for the
size of the interrupt table was forgotten"
* tag 'iommu-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs
|
|
The validity of the ftdi CBUS GPIO is pretty hidden so far,
and finding out *why* some GPIOs don't work is sometimes
hard to identify. So let's help the user by displaying the
map of the CBUS pins that are valid for a GPIO.
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201204164739.781812-4-maz@kernel.org
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
[johan: demote to KERN_DEBUG, rephrase messages, drop ftx-prog warning]
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Now that gpiolib can track the validity of GPIO pins, there is no need
to check whether the line is valid in request().
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201204164739.781812-5-maz@kernel.org
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
[johan: amend commit message]
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Since it is pretty common for only some of the CBUS lines to be
valid as GPIO lines, let's report such validity to the rest of
the kernel.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201204164739.781812-3-maz@kernel.org
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
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>
|
|
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>
|
|
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: a17d94f0b6e1 ("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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Flash update failed due to missing endian conversion in FLT region access
as well as in checksum computation.
Link: https://lore.kernel.org/r/20201202132312.19966-12-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>
|
|
Call trace observed while shutting down the adapter ports (LINK DOWN).
Handle aborts correctly.
localhost kernel: INFO: task nvme:44209 blocked for more than 120 seconds.
localhost kernel: "echo 0 >/proc/sys/kernel/hung_task_timeout_secs" disables this message.
localhost kernel: nvme D ffff88b45fb5acc0 0 44209 1 0x00000080
localhost kernel: Call Trace:
localhost kernel: [<ffffffffbd187169>] schedule+0x29/0x70
localhost kernel: [<ffffffffbd184c51>] schedule_timeout+0x221/0x2d0
localhost kernel: [<ffffffffbcad7229>] ? ttwu_do_wakeup+0x19/0xe0
localhost kernel: [<ffffffffbcad735f>] ? ttwu_do_activate+0x6f/0x80
localhost kernel: [<ffffffffbcada830>] ? try_to_wake_up+0x190/0x390
localhost kernel: [<ffffffffbd18751d>] wait_for_completion+0xfd/0x140
localhost kernel: [<ffffffffbcadaaf0>] ? wake_up_state+0x20/0x20
localhost kernel: [<ffffffffbcabe3da>] flush_work+0x10a/0x1b0
localhost kernel: [<ffffffffbcabb0f0>] ? move_linked_works+0x90/0x90
localhost kernel: [<ffffffffbcabe6cf>] flush_delayed_work+0x3f/0x50
localhost kernel: [<ffffffffc0452767>] nvme_fc_init_ctrl+0x657/0x6a0 [nvme_fc]
localhost kernel: [<ffffffffc045293a>] nvme_fc_create_ctrl+0x18a/0x210 [nvme_fc]
localhost kernel: [<ffffffffc028962f>] nvmf_dev_write+0x98f/0xb35 [nvme_fabrics]
localhost kernel: [<ffffffffbcd08927>] ? security_file_permission+0x27/0xa0
localhost kernel: [<ffffffffbcc4db50>] vfs_write+0xc0/0x1f0
localhost kernel: [<ffffffffbcc4e92f>] SyS_write+0x7f/0xf0
localhost kernel: [<ffffffffbd193f92>] system_call_fastpath+0x25/0x2a
Link: https://lore.kernel.org/r/20201202132312.19966-11-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>
|
|
FC-NVMe target discovery failed when initiator wwpn < target wwpn in an N2N
(Direct Attach) config, where the driver was stuck on FCP PRLI mode and
failed to retry with NVMe PRLI.
Link: https://lore.kernel.org/r/20201202132312.19966-10-njavali@marvell.com
Fixes: 84ed362ac40c ("scsi: qla2xxx: Dual FCP-NVMe target port support”)
Fixes: 983f127603fa ("scsi: qla2xxx: Retry PLOGI on FC-NVMe PRLI failure”)
Signed-off-by: Quinn Tran <qutran@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Some fields are not correctly byte swapped causing failure during
initialization. As probe() returns failure, HBAs will not be claimed when
this happens.
qla2xxx [0007:01:00.0]-ffff:3: Secure Flash Update in FW: Supported
qla2xxx [0007:01:00.0]-ffff:3: SCM in FW: Supported
qla2xxx [0007:01:00.0]-00d2:3: Init Firmware **** FAILED ****.
qla2xxx [0007:01:00.0]-00d6:3: Failed to initialize adapter - Adapter flags 2.
qla2xxx 0007:01:00.1: enabling device (0140 -> 0142)
qla2xxx [0007:01:00.1]-011c: : MSI-X vector count: 128.
qla2xxx [0007:01:00.1]-001d: : Found an ISP2289 irq 18 iobase 0xd000080080004000.
qla2xxx 0007:01:00.1: Using 64-bit direct DMA at offset 800000000000000
BUG: Bad page state in process insmod pfn:67118 page:f00000000168bd40
count:-1 mapcount:0 mapping: (null) index:0x0
page flags: 0x3ffff800000000() page dumped because: nonzero _count
Modules linked in: qla2xxx(OE+) nvme_fc nvme_fabrics
nvme_core scsi_transport_fc scsi_tgt nls_utf8 isofs ip6t_rpfilter
ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set
nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
iptable_security iptable_raw ebtable_filter ebtables ip6table_filter
ip6_tables iptable_filter nx_crypto ses enclosure scsi_transport_sas
pseries_rng sg ip_tables xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif
crct10dif_generic crct10dif_common usb_storage ipr libata tg3 ptp
pps_core dm_mirror dm_region_hash dm_log dm_mod
CPU: 32 PID: 8560 Comm: insmod Kdump: loaded Tainted: G
OE ------------ 3.10.0-957.el7.ppc64 #1
Call Trace:
[c0000006dd7caa70] [c00000000001cca8] .show_stack+0x88/0x330 (unreliable)
[c0000006dd7cab30] [c000000000ac3d88] .dump_stack+0x28/0x3c
[c0000006dd7caba0] [c00000000029e48c] .bad_page+0x15c/0x1c0
[c0000006dd7cac40] [c00000000029f938] .get_page_from_freelist+0x11e8/0x1ea0
[c0000006dd7caf40] [c0000000002a1d30] .__alloc_pages_nodemask+0x1c0/0xc70
[c0000006dd7cb140] [c00000000002ba0c] .__dma_direct_alloc_coherent+0x8c/0x170
[c0000006dd7cb1e0] [d000000010a94688] .qla2x00_mem_alloc+0x10f8/0x1370 [qla2xxx]
[c0000006dd7cb2d0] [d000000010a9c790] .qla2x00_probe_one+0xb60/0x22e0 [qla2xxx]
[c0000006dd7cb540] [c0000000005de764] .pci_device_probe+0x204/0x300
[c0000006dd7cb600] [c0000000006ca61c] .driver_probe_device+0x2cc/0x6f0
[c0000006dd7cb6b0] [c0000000006cabec] .__driver_attach+0x10c/0x110
[c0000006dd7cb740] [c0000000006c5f04] .bus_for_each_dev+0x94/0x100
[c0000006dd7cb7e0] [c0000000006c94f4] .driver_attach+0x34/0x50
[c0000006dd7cb860] [c0000000006c8f58] .bus_add_driver+0x298/0x3b0
[c0000006dd7cb900] [c0000000006cb6e0] .driver_register+0xb0/0x1a0
[c0000006dd7cb980] [c0000000005dc474] .__pci_register_driver+0xc4/0xf0
[c0000006dd7cba10] [d000000010b94e20] .qla2x00_module_init+0x2a8/0x328 [qla2xxx]
[c0000006dd7cbaa0] [c00000000000c130] .do_one_initcall+0x130/0x2e0
[c0000006dd7cbb50] [c0000000001b2e8c] .load_module+0x1afc/0x2340
[c0000006dd7cbd40] [c0000000001b3920] .SyS_finit_module+0xd0/0x130
[c0000006dd7cbe30] [c00000000000a284] system_call+0x38/0xfc
Link: https://lore.kernel.org/r/20201202132312.19966-9-njavali@marvell.com
Fixes: 9f2475fe7406 ("scsi: qla2xxx: SAN congestion management implementation")
Fixes: cf3c54fb49a4 ("scsi: qla2xxx: Add SLER and PI control support”)
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>
|
|
Crash stack:
[576544.715489] Unable to handle kernel paging request for data at address 0xd00000000f970000
[576544.715497] Faulting instruction address: 0xd00000000f880f64
[576544.715503] Oops: Kernel access of bad area, sig: 11 [#1]
[576544.715506] SMP NR_CPUS=2048 NUMA pSeries
:
[576544.715703] NIP [d00000000f880f64] .qla27xx_fwdt_template_valid+0x94/0x100 [qla2xxx]
[576544.715722] LR [d00000000f7952dc] .qla24xx_load_risc_flash+0x2fc/0x590 [qla2xxx]
[576544.715726] Call Trace:
[576544.715731] [c0000004d0ffb000] [c0000006fe02c350] 0xc0000006fe02c350 (unreliable)
[576544.715750] [c0000004d0ffb080] [d00000000f7952dc] .qla24xx_load_risc_flash+0x2fc/0x590 [qla2xxx]
[576544.715770] [c0000004d0ffb170] [d00000000f7aa034] .qla81xx_load_risc+0x84/0x1a0 [qla2xxx]
[576544.715789] [c0000004d0ffb210] [d00000000f79f7c8] .qla2x00_setup_chip+0xc8/0x910 [qla2xxx]
[576544.715808] [c0000004d0ffb300] [d00000000f7a631c] .qla2x00_initialize_adapter+0x4dc/0xb00 [qla2xxx]
[576544.715826] [c0000004d0ffb3e0] [d00000000f78ce28] .qla2x00_probe_one+0xf08/0x2200 [qla2xxx]
Link: https://lore.kernel.org/r/20201202132312.19966-8-njavali@marvell.com
Fixes: f73cb695d3ec ("[SCSI] qla2xxx: Add support for ISP2071.")
Cc: stable@vger.kernel.org
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>
|
|
Fix compile time errors reported on PPC systems,
qla_gbl.h:991:20: error: inlining failed in call to always_inline
‘qla_nvme_abort_set_option’: function body not available
Link: https://lore.kernel.org/r/20201202132312.19966-7-njavali@marvell.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>
|
|
NVMe commands can come only after successful addition of rport and NVMe
connect, and rport is only registered after FW started bit is set. Remove
the redundant check.
Link: https://lore.kernel.org/r/20201202132312.19966-6-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>
|
|
The completion status 0x28 (ppc = be = 0x2800) below indicates session is
not there, trigger session deletion.
qla2xxx [000b:04:00.1]-8009:8: DEVICE RESET ISSUED nexus=8:1:51 cmd=c000001432d0f600.
qla2xxx [000b:04:00.1]-5039:8: Async-tmf error - hdl=67b completion status(2800).
qla2xxx [000b:04:00.1]-8030:8: TM IOCB failed (102).
qla2xxx [000b:04:00.1]-800c:8: do_reset failed for cmd=c000001432d0f600.
qla2xxx [000b:04:00.1]-800f:8: DEVICE RESET FAILED: Task management failed nexus=8:1:51 cmd=c000001432d0f600.
qla2xxx [000b:04:00.1]-8009:8: DEVICE RESET ISSUED nexus=8:1:52 cmd=c000001432d0c200.
qla2xxx [000b:04:00.1]-5039:8: Async-tmf error - hdl=67c completion status(2800).
qla2xxx [000b:04:00.1]-8030:8: TM IOCB failed (102).
Link: https://lore.kernel.org/r/20201202132312.19966-5-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Quinn Tran <qutran@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
