The driver supports a "direct" mode of operation, where the SMP req frame
is directly copied into the command payload (and vice-versa for the SMP
resp).

To get at the SMP req frame data in the scatterlist the driver uses
phys_to_virt() on the DMA mapped memory dma_addr_t . This is broken, and
subsequently crashes as follows when an IOMMU is enabled:

 Unable to handle kernel paging request at virtual address
ffff0000fcebfb00
	...
 pc : pm80xx_chip_smp_req+0x2d0/0x3d0
 lr : pm80xx_chip_smp_req+0xac/0x3d0
 pm80xx_chip_smp_req+0x2d0/0x3d0
 pm8001_task_exec.constprop.0+0x368/0x520
 pm8001_queue_command+0x1c/0x30
 smp_execute_task_sg+0xdc/0x204
 sas_discover_expander.part.0+0xac/0x6cc
 sas_discover_root_expander+0x8c/0x150
 sas_discover_domain+0x3ac/0x6a0
 process_one_work+0x1d0/0x354
 worker_thread+0x13c/0x470
 kthread+0x17c/0x190
 ret_from_fork+0x10/0x20
 Code: 371806e1 910006d6 6b16033f 54000249 (38766b05)
 ---[ end trace b91d59aaee98ea2d ]---
note: kworker/u192:0[7] exited with preempt_count 1

Instead use kmap_atomic().

--
Difference to v1:
- use kmap_atomic() in both locations
Difference to  v2:
- add whitespace around arithmetic (Damien)

Link: https://lore.kernel.org/r/1639390248-213603-1-git-send-email-john.garry@huawei.comReviewed-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

This is a follow up cleanup to the commit 924a3541 ("scsi: libsas:
aic94xx: hisi_sas: mvsas: pm8001: Use dev_is_expander()")

Link: https://lore.kernel.org/r/20210929025807.646589-1-ipylypiv@google.comReviewed-by: NVishakha Channapattan <vishakhavc@google.com>
Acked-by: NJack Wang <jinpu.wang@ionos.com>
Signed-off-by: NIgor Pylypiv <ipylypiv@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Commit 1f02beff ("scsi: pm80xx: Remove global lock from outbound queue
processing") introduced a lock per outbound queue. Prior to that change the
driver was using a global lock for all outbound queues.

While processing the I/O responses and events the driver takes the outbound
queue spinlock and is supposed to release it in pm8001_ccb_task_free_done()
before calling command done(). Since the older code was using a global
lock, pm8001_ccb_task_free_done() was releasing the global spin lock. The
change that split the lock per outbound queue did not consider this and
pm8001_ccb_task_free_done() was still releasing the global lock.

Link: https://lore.kernel.org/r/20210906170404.5682-3-Ajish.Koshy@microchip.com
Fixes: 1f02beff ("scsi: pm80xx: Remove global lock from outbound queue processing")
Acked-by: NJack Wang <jinpu.wang@ionos.com>
Signed-off-by: NAjish Koshy <Ajish.Koshy@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

During phyup event, the firmware provides the phy_id and port_id and driver
is supposed to use these during device handle registration. Previously the
driver was using the port id value from libsas during device handle
registration. Since id can be different from the one assigned by firmware,
this can lead to wrong device registration and drives not showing up.

Use firmware assigned port id during device registration.

Link: https://lore.kernel.org/r/20210906170404.5682-2-Ajish.Koshy@microchip.comAcked-by: NJack Wang <jinpu.wang@ionos.com>
Signed-off-by: NAjish Koshy <Ajish.Koshy@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Fix kernel-doc warnings then test again, wash, rinse, find more, then
repeat more/again.

Also fix spellos, some grammar, and some punctuation.

../drivers/scsi/pm8001/pm8001_ctl.c:557: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 ** pm8001_ctl_fatal_log_show - fatal error logging
../drivers/scsi/pm8001/pm8001_ctl.c:577: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 ** non_fatal_log_show - non fatal error logging
../drivers/scsi/pm8001/pm8001_ctl.c:622: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 ** pm8001_ctl_gsm_log_show - gsm dump collection

Link: https://lore.kernel.org/r/20210708165723.8594-1-rdunlap@infradead.org
Cc: Jack Wang <jinpu.wang@cloud.ionos.com>
Cc: linux-scsi@vger.kernel.org
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Acked-by: NJack Wang <jinpu.wang@ionos.com>
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

This patch prepares for converting SAM status codes into an enum. Without
this patch converting SAM status codes into an enumeration type would
trigger complaints about enum type mismatches for the SAS code.

Link: https://lore.kernel.org/r/20210524025457.11299-2-bvanassche@acm.org
Cc: Hannes Reinecke <hare@suse.com>
Cc: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
Cc: Jason Yan <yanaijie@huawei.com>
Reviewed-by: NJohn Garry <john.garry@huawei.com>
Reviewed-by: NHimanshu Madhani <himanshu.madhani@oracle.com>
Acked-by: NJack Wang <jinpu.wang@ionos.com>
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

When driver is loaded after rmmod some drives are not showing up during
discovery.

SATA drives are directly attached to the controller connected phys.  During
device discovery, the IDENTIFY command (qc timeout (cmd 0xec)) is timing out
during revalidation. This will trigger abort from host side and controller
successfully aborts the command and returns success. Post this successful
abort response ATA library decides to mark the disk as NODEV.

To overcome this, inside pm8001_scan_start() after phy_start() call, add get
start response and wait for few milliseconds to trigger next phy start.
This millisecond delay will give sufficient time for the controller state
machine to accept next phy start.

Link: https://lore.kernel.org/r/20210505120103.24497-1-ajish.koshy@microchip.comSigned-off-by: NAjish Koshy <ajish.koshy@microchip.com>
Signed-off-by: NViswas G <viswas.g@microchip.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Introduce spin lock for outbound queue. With this, driver need not acquire
HBA global lock for outbound queue processing.

Link: https://lore.kernel.org/r/20210415103352.3580-9-Viswas.G@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NAshokkumar N <Ashokkumar.N@microchip.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Producer index(PI) outbound queue and consumer index(CI) for Outbound queue
are in DMA memory. During resume(), the stale PI and CI Values will lead to
unexpected behavior. These values should be reset to 0 during driver
reinitialization.

Link: https://lore.kernel.org/r/20210415103352.3580-8-Viswas.G@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NAshokkumar N <Ashokkumar.N@microchip.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

When controller runs into fatal error, I/Os get stuck with no response,
handler event is defined to complete the pending I/Os (SAS task and
internal task) and also perform the cleanup for the drives.

Link: https://lore.kernel.org/r/20210415103352.3580-7-Viswas.G@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NAshokkumar N <Ashokkumar.N@microchip.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

checkpatch reports the following:

    ERROR: space prohibited before that ',' (ctx:WxW)
    +int pm8001_mpi_general_event(struct pm8001_hba_info *pm8001_ha , void *piomb);

Remove unnecessary whitespace.

Link: https://lore.kernel.org/r/1617886593-36421-2-git-send-email-luojiaxing@huawei.comAcked-by: NJack Wang <jinpu.wang@ionos.com>
Signed-off-by: NLuo Jiaxing <luojiaxing@huawei.com>
Signed-off-by: NJianqin Xie <xiejianqin@hisilicon.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

mpi_uninit_check() is not being called in an atomic context.  The only
caller of mpi_uninit_check() is pm80xx_chip_soft_rst().

Callers of pm80xx_chip_soft_rst():

 - pm8001_ioctl_soft_reset()
 - pm8001_pci_probe()
 - pm8001_pci_remove()
 - pm8001_pci_suspend()
 - pm8001_pci_resume()

There was a similar fix for mpi_init_check() in commit
d71023af ("scsi: pm80xx: Do not busy wait in MPI init check")

Link: https://lore.kernel.org/r/20210406180534.1924345-3-ipylypiv@google.comReviewed-by: NVishakha Channapattan <vishakhavc@google.com>
Acked-by: NJack Wang <jinpu.wang@ionos.com>
Signed-off-by: NIgor Pylypiv <ipylypiv@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The mpi_uninit_check() takes longer for inbound doorbell register to be
cleared. Increase the timeout substantially so that the driver does not
fail to load.

Previously, the inbound doorbell wait time was mistakenly increased in the
mpi_init_check() instead of mpi_uninit_check(). It is okay to leave the
mpi_init_check() wait time as-is as these are timeout values and if there
is a failure, waiting longer is not an issue.

Link: https://lore.kernel.org/r/20210406180534.1924345-2-ipylypiv@google.com
Fixes: e90e2362 ("scsi: pm80xx: Increase timeout for pm80xx mpi_uninit_check")
Reviewed-by: NVishakha Channapattan <vishakhavc@google.com>
Acked-by: NJack Wang <jinpu.wang@ionos.com>
Signed-off-by: NIgor Pylypiv <ipylypiv@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/pm8001/pm80xx_hwi.c:1427: warning: expecting prototype for pm8001_chip_init(). Prototype was for pm80xx_chip_init() instead
 drivers/scsi/pm8001/pm80xx_hwi.c:1584: warning: expecting prototype for pm8001_chip_soft_rst(). Prototype was for pm80xx_chip_soft_rst() instead
 drivers/scsi/pm8001/pm80xx_hwi.c:1711: warning: expecting prototype for pm8001_chip_interrupt_enable(). Prototype was for pm80xx_chip_intx_interrupt_enable() instead
 drivers/scsi/pm8001/pm80xx_hwi.c:1722: warning: expecting prototype for pm8001_chip_intx_interrupt_disable(). Prototype was for pm80xx_chip_intx_interrupt_disable() instead
 drivers/scsi/pm8001/pm80xx_hwi.c:1733: warning: expecting prototype for pm8001_chip_interrupt_enable(). Prototype was for pm80xx_chip_interrupt_enable() instead
 drivers/scsi/pm8001/pm80xx_hwi.c:1752: warning: expecting prototype for pm8001_chip_interrupt_disable(). Prototype was for pm80xx_chip_interrupt_disable() instead
 drivers/scsi/pm8001/pm80xx_hwi.c:4192: warning: expecting prototype for pm8001_chip_smp_req(). Prototype was for pm80xx_chip_smp_req() instead
 drivers/scsi/pm8001/pm80xx_hwi.c:4775: warning: expecting prototype for pm8001_chip_phy_stop_req(). Prototype was for pm80xx_chip_phy_stop_req() instead
 drivers/scsi/pm8001/pm80xx_hwi.c:4907: warning: expecting prototype for pm8001_chip_isr(). Prototype was for pm80xx_chip_isr() instead

Link: https://lore.kernel.org/r/20210303144631.3175331-23-lee.jones@linaro.org
Cc: Jack Wang <jinpu.wang@cloud.ionos.com>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Acked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

libsas event notifiers required an extension where gfp_t flags must be
explicitly passed. For bisectability, a temporary _gfp() variant of such
functions were added. All call sites then got converted use the _gfp()
variants and explicitly pass GFP context. Having no callers left, the
original libsas notifiers were then modified to accept gfp_t flags by
default.

Switch back to the original libas API, while still passing GFP context.
The libsas _gfp() variants will be removed afterwards.

Link: https://lore.kernel.org/r/20210118100955.1761652-16-a.darwish@linutronix.de
Cc: Jack Wang <jinpu.wang@cloud.ionos.com>
Reviewed-by: NJohn Garry <john.garry@huawei.com>
Reviewed-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NAhmed S. Darwish <a.darwish@linutronix.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Use the new libsas event notifiers API, which requires callers to
explicitly pass the gfp_t memory allocation flags.

Call chain analysis, pm8001_hwi.c:

  pm8001_interrupt_handler_msix() || pm8001_interrupt_handler_intx() || pm8001_tasklet()
    -> PM8001_CHIP_DISP->isr() = pm80xx_chip_isr()
      -> process_oq [spin_lock_irqsave(&pm8001_ha->lock, ...)]
        -> process_one_iomb()
          -> mpi_hw_event()
            -> hw_event_sas_phy_up()
              -> pm8001_bytes_dmaed()
            -> hw_event_sata_phy_up
              -> pm8001_bytes_dmaed()

All functions are invoked by process_one_iomb(), which is invoked by the
interrupt service routine and the tasklet handler. A similar call chain is
also found at pm80xx_hwi.c. Pass GFP_ATOMIC.

For pm8001_sas.c, pm8001_phy_control() runs in task context as it calls
wait_for_completion() and msleep().  Pass GFP_KERNEL.

Link: https://lore.kernel.org/r/20210118100955.1761652-10-a.darwish@linutronix.de
Cc: Jack Wang <jinpu.wang@cloud.ionos.com>
Reviewed-by: NJohn Garry <john.garry@huawei.com>
Reviewed-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NAhmed S. Darwish <a.darwish@linutronix.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

LLDDs report events to libsas with .notify_port_event and .notify_phy_event
callbacks.

These callbacks are fixed and so there is no reason why the functions
cannot be called directly, so do that.

This neatens the code slightly, makes it more obvious, and reduces function
pointer usage, which is generally a good thing. Downside is that there are
2x more symbol exports.

[a.darwish@linutronix.de: Remove the now unused "sas_ha" local variables]

Link: https://lore.kernel.org/r/20210118100955.1761652-3-a.darwish@linutronix.deReviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Signed-off-by: NAhmed S. Darwish <a.darwish@linutronix.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

A block of code is indented one level too deeply, clean this up.

Link: https://lore.kernel.org/r/20210115095824.9170-1-colin.king@canonical.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Addresses-Coverity: ("Indentation does not match nesting level")

Added a log message in SATA completion path to capture the status of failed
command. If the status does not match any expected status, another message
will be logged.

On IO failure with known status, the log message will be:

  [ 1712.951735] pm80xx0:: mpi_sata_completion 2269: IO failed device_id 16385 status 0x1 tag XX

If the firmware returns unexpected status, a message of the following
format will be logged:

  [ 1712.951735] pm80xx0:: mpi_sata_completion XXXX: Unknown status device_id XXXXX status 0xX tag XX

Link: https://lore.kernel.org/r/20210109123849.17098-8-Viswas.G@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NVishakha Channapattan <vishakhavc@google.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NAshokkumar N <Ashokkumar.N@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

In check_fw_ready() we first wait for ILA to come up and then we wait for
RAAE to come up and IOPs and so on. This is a sequential check.  Because of
this, ILA image seems to be not ready in the allocated time and so the
driver marks it as "not ready" and then moves on to other FW images.

ILA does become ready eventually, but is not checked again. The driver
concludes that FW is not ready when it actually is.

Instead of sequentially polling each image, we keep polling for all images
to be ready. The timeout for the polling has been set to the sum of what
was used for each individual image.

Link: https://lore.kernel.org/r/20210109123849.17098-7-Viswas.G@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NBhavesh Jashnani <bjashnani@google.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NAshokkumar N <Ashokkumar.N@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The function pm80xx_get_fatal_dump() has two issues that result in the
fatal dump not being able to complete successfully.

 1. Trying to collect fatal_logs from the application fails because we are
    not shifting the MEMBASE-II register properly. Once we read 64K region
    of data we have to shift the MEMBASE-II register and read the next
    chunk. Only then would we be able to get complete data.

 2. If a timeout occurs, our application will get stuck.

Link: https://lore.kernel.org/r/20210109123849.17098-6-Viswas.G@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NAshokkumar N <Ashokkumar.N@microchip.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The driver initializes main configuration, general status, inbound queue
and outbound queue table addresses based on a value read from
MSGU_SCRATCH_PAD_0 register.

We should validate these addresses before dereferencing them.

Adds two validations:

 1. Check if main configuration table offset lies within the pcibar
    mapped

 2. Check if first dword of main configuration table reads "PMCS"

There are two calls to init_pci_device_addresses() done during
pm8001_pci_probe() in this sequence:

 1. First inside chip_soft_rst, where if init_pci_device_addresses fails we
    will go ahead assuming MPI state is not ready and reset the device as
    long as bootloader is okay.  This gives chance to second call of
    init_pci_device_addresses to set up the addresses after reset.

 2. The second call is via pm80xx_chip_init, after soft reset is done and
    firmware is checked to be ready. Once that is done we are safe to go
    ahead and initialize default table values and use them.

Tests:

 1. Enabled debugging logs and observed no issues during initialization,
    with a controller with no issues:

    pm80xx0:: pm8001_setup_msix 1034: pci_alloc_irq_vectors request ret:64 no of intr 64
    pm80xx0:: init_pci_device_addresses 917: Scratchpad 0 Offset: 0x2000 value 0x40002000
    pm80xx0:: init_pci_device_addresses 925: Scratchpad 0 PCI BAR: 0
    pm80xx0:: init_pci_device_addresses 952: VALID main config signature 0x53434d50
    pm80xx0:: init_pci_device_addresses 975: GST OFFSET 0xc4
    pm80xx0:: init_pci_device_addresses 978: INBND OFFSET 0x20000128
    pm80xx0:: init_pci_device_addresses 981: OBND OFFSET 0x24000928
    pm80xx0:: init_pci_device_addresses 984: IVT OFFSET 0x8001408
    pm80xx0:: init_pci_device_addresses 987: PSPA OFFSET 0x8001608
    pm80xx0:: init_pci_device_addresses 991: addr - main cfg (ptrval) general status (ptrval)
    pm80xx0:: init_pci_device_addresses 995: addr - inbnd (ptrval) obnd (ptrval)
    pm80xx0:: init_pci_device_addresses 999: addr - pspa (ptrval) ivt (ptrval)
    pm80xx0:: pm80xx_chip_soft_rst 1446: reset register before write : 0x0
    pm80xx0:: pm80xx_chip_soft_rst 1478: reset register after write 0x40
    pm80xx0:: pm80xx_chip_soft_rst 1544: SPCv soft reset Complete
    pm80xx0:: init_pci_device_addresses 917: Scratchpad 0 Offset: 0x2000 value 0x40002000
    pm80xx0:: init_pci_device_addresses 925: Scratchpad 0 PCI BAR: 0
    pm80xx0:: init_pci_device_addresses 952: VALID main config signature 0x53434d50
    pm80xx0:: init_pci_device_addresses 975: GST OFFSET 0xc4
    pm80xx0:: init_pci_device_addresses 978: INBND OFFSET 0x20000128
    pm80xx0:: init_pci_device_addresses 981: OBND OFFSET 0x24000928
    pm80xx0:: init_pci_device_addresses 984: IVT OFFSET 0x8001408
    pm80xx0:: init_pci_device_addresses 987: PSPA OFFSET 0x8001608
    pm80xx0:: init_pci_device_addresses 991: addr - main cfg (ptrval) general status (ptrval)
    pm80xx0:: init_pci_device_addresses 995: addr - inbnd (ptrval) obnd (ptrval)
    pm80xx0:: init_pci_device_addresses 999: addr - pspa (ptrval) ivt (ptrval)
    pm80xx0:: pm80xx_chip_init 1329: MPI initialize successful!

 2. Tested controller with firmware known to have initialization issue and
    observed no crashes with this fix:

    pm80xx 0000:01:00.0: pm80xx: driver version 0.1.38
    pm80xx 0000:01:00.0: Removing from 1:1 domain
    pm80xx 0000:01:00.0: Requesting non-1:1 mappings
    pm80xx0:: init_pci_device_addresses 948: BAD main config signature 0x0
    pm80xx0:: mpi_uninit_check 1365: Failed to init pci addresses
    pm80xx0:: pm80xx_chip_soft_rst 1435: MPI state is not ready scratch:0:8:62a01000:0
    pm80xx0:: pm80xx_chip_soft_rst 1518: Firmware is not ready!
    pm80xx0:: pm80xx_chip_soft_rst 1532: iButton Feature is not Available!!!
    pm80xx0:: pm80xx_chip_init 1301: Firmware is not ready!
    pm80xx0:: pm8001_pci_probe 1215: chip_init failed [ret: -16]
    pm80xx: probe of 0000:01:00.0 failed with error -16
    pm80xx 0000:07:00.0: pm80xx: driver version 0.1.38
    pm80xx 0000:07:00.0: Removing from 1:1 domain
    pm80xx 0000:07:00.0: Requesting non-1:1 mappings
    scsi host6: pm80xx
    pm80xx1:: pm8001_setup_sgpio 5568: failed sgpio_req timeout
    pm80xx1:: mpi_phy_start_resp 3447: phy start resp status:0x0, phyid:0x0
    pm80xx 0000:08:00.0: pm80xx: driver version 0.1.38
    pm80xx 0000:08:00.0: Removing from 1:1 domain
    pm80xx 0000:08:00.0: Requesting non-1:1 mappings

 3. Without this fix we observe crash on the same controller:

    pm80xx 0000:01:00.0: pm80xx: driver version 0.1.38
    pm80xx 0000:01:00.0: Removing from 1:1 domain
    pm80xx 0000:01:00.0: Requesting non-1:1 mappings
    [<ffffffffc0451b3b>] pm80xx_chip_soft_rst+0x6b/0x4c0 [pm80xx]
    [<ffffffffc043a933>] pm8001_pci_probe+0xa43/0x1630 [pm80xx]
    RIP: 0010:pm80xx_chip_soft_rst+0x71/0x4c0 [pm80xx]
    [<ffffffffc0451b3b>] ? pm80xx_chip_soft_rst+0x6b/0x4c0 [pm80xx]
    [<ffffffffc043a933>] pm8001_pci_probe+0xa43/0x1630 [pm80xx]
    pm80xx0:: mpi_uninit_check 1339: TIMEOUT:IBDB value/=2
    pm80xx0:: pm80xx_chip_soft_rst 1387: MPI state is not ready scratch:0:8:62a01000:0
    pm80xx0:: pm80xx_chip_soft_rst 1470: Firmware is not ready!
    pm80xx0:: pm80xx_chip_soft_rst 1484: iButton Feature is not Available!!!
    pm80xx0:: pm80xx_chip_init 1266: Firmware is not ready!
    pm80xx0:: pm8001_pci_probe 1207: chip_init failed [ret: -16]
    pm80xx: probe of 0000:01:00.0 failed with error -16

Link: https://lore.kernel.org/r/20210109123849.17098-4-Viswas.G@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Nakshatzen <akshatzen@google.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

When the controller runs into a fatal error, commands get stuck due to no
response. If the controller is in fatal error state, abort requests issued
to the controller get stuck too.

Check the controller state for fatal error conditions.

Link: https://lore.kernel.org/r/20210109123849.17098-3-Viswas.G@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Nakshatzen <akshatzen@google.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

We do not need to busy wait during mpi_init_check() since it is not being
invoked in atomic context. mpi_init_check() is being called from
pm8001_pci_resume(), pm8001_pci_probe(). Hence we are replacing udelay with
msleep.

Link: https://lore.kernel.org/r/20210109123849.17098-2-Viswas.G@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Nakshatzen <akshatzen@google.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

hw_event_sas_phy_up() is used in hardirq/softirq context:

 pm8001_interrupt_handler_msix() || pm8001_interrupt_handler_intx() || pm8001_tasklet
   => PM8001_CHIP_DISP->isr() = pm80xx_chip_isr()
     => process_oq() [spin_lock_irqsave(&pm8001_ha->lock,)]
       => process_one_iomb()
         => mpi_hw_event()
           => hw_event_sas_phy_up()
             => msleep(200)

Revert the msleep() back to an mdelay() to avoid sleeping in atomic
context.

Link: https://lore.kernel.org/r/20201126132952.2287996-2-bigeasy@linutronix.de
Fixes: 4daf1ef3 ("scsi: pm80xx: Convert 'long' mdelay to msleep")
Cc: Vikram Auradkar <auradkar@google.com>
Cc: Jack Wang <jinpu.wang@cloud.ionos.com>
Acked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NAhmed S. Darwish <a.darwish@linutronix.de>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Every PM8001_<FOO>_DBG macro uses an internal call to pm8001_printk.

Convert all uses of:

	PM8001_<FOO>_DBG(hba, pm8001_printk(fmt, ...))
to
	pm8001_dbg(hba, <FOO>, fmt, ...)

so the visual complexity of each macro is reduced.

The repetitive macro definitions are converted to a single pm8001_dbg and
the level is concatenated using PM8001_##level##_LOGGING for the specific
level test.

Done with coccinelle, checkpatch and a little typing of the new macro
definition.

Miscellanea:

 - Coalesce formats

 - Realign arguments

 - Add missing terminating newlines to formats

 - Remove trailing spaces from formats

 - Change defective loop with printk(KERN_INFO... to emit a 16 byte hex
   block to %p16h

Link: https://lore.kernel.org/r/49f36a93af7752b613d03c89a87078243567fd9a.1605914030.git.joe@perches.comReported-by: Nkernel test robot <lkp@intel.com>
Acked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

In function check_fw_ready() we busy wait using udelay. The CPU is not
released and we see need_resched failures.

Busy waiting is not necessary since we are in process context and we can
sleep instead. Replace udelay with msleep of 20 ms intervals while waiting
for firmware to become ready.

It has been verified that check_fw_ready is not being used in interrupt
context anywhere, hence it is safe to make this change.

Link: https://lore.kernel.org/r/20201102165528.26510-4-Viswas.G@microchip.com.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Nakshatzen <akshatzen@google.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Incorrect value of the running_req was causing the driver unload to be
stuck during the SAS lldd_dev_gone notification handling.  During SATA I/O
completion, for some error status values, the driver schedules the event
handler and running_req is decremented from that.  However, there are some
other error status values (like IO_DS_IN_RECOVERY,
IO_XFER_ERR_LAST_PIO_DATAIN_CRC_ERR) where the I/O has already been
completed by fw/driver so running_req is not decremented.

Also during NCQ error handling, driver itself will initiate READ_LOG_EXT
and ABORT_ALL. When libsas/libata initiate READ_LOG_EXT (0x2F), driver
increments running_req. This will be completed by the driver in
pm80xx_chip_sata_req(), but running_req was not decremented.

Link: https://lore.kernel.org/r/20201102165528.26510-3-Viswas.G@microchip.com.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Driver submits all internal requests (like abort_task, event acknowledgment
etc.) through inbound queue 0. While submitting those, driver does not
acquire any lock and this may lead to a race when there is an I/O request
coming in on CPU0 and submitted through inbound queue 0.  To avoid this,
lock acquisition has been moved to pm8001_mpi_build_cmd().  All command
submission will go through this path.

Link: https://lore.kernel.org/r/20201102165528.26510-2-Viswas.G@microchip.com.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Npeter chang <dpf@google.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The pm80xx driver currently sets the controller queue depth to
256. Hoewver, the controller supports outstanding I/Os up 1024.

Increase the number of outstanding I/Os from 256 to 1024.  CCBs and tags
are allocated according to outstanding I/Os. Also update the can_queue
value (max_out_io - PM8001_RESERVE_SLOT) used by the SCSI midlayer.

[mkp: fixed zeroday complaint]

Link: https://lore.kernel.org/r/20201005145011.23674-4-Viswas.G@microchip.com.comReported-by: Nkernel test robot <lkp@intel.com>
Acked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Current driver uses fixed number of Inbound and Outbound queues and all of
the I/O, TMF and internal requests are submitted through those. A global
spin lock is used to control the shared access. This can create a lock
contention and it is real bottleneck in the I/O path.

To avoid this, the number of supported Inbound and Outbound queues is
increased to 64, and the number of queues used is decided based on number
of CPU cores online and number of MSI-X vectors allocated. Also add locks
per queue instead of using the global lock.

Link: https://lore.kernel.org/r/20201005145011.23674-2-Viswas.G@microchip.com.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRuksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

These are not invoked externally.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/pm8001/pm80xx_hwi.c:69:6: warning: no previous prototype for ‘pm80xx_pci_mem_copy’ [-Wmissing-prototypes]
 69 | void pm80xx_pci_mem_copy(struct pm8001_hba_info *pm8001_ha, u32 soffset,
 | ^~~~~~~~~~~~~~~~~~~
 drivers/scsi/pm8001/pm80xx_hwi.c:5016:6: warning: no previous prototype for ‘mpi_set_phy_profile_req’ [-Wmissing-prototypes]
 5016 | void mpi_set_phy_profile_req(struct pm8001_hba_info *pm8001_ha,
 | ^~~~~~~~~~~~~~~~~~~~~~~

Link: https://lore.kernel.org/r/20200721164148.2617584-26-lee.jones@linaro.org
Cc: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/pm8001/pm80xx_hwi.c:918: warning: Function parameter or member 'number' not described in 'update_inbnd_queue_table'
 drivers/scsi/pm8001/pm80xx_hwi.c:954: warning: Function parameter or member 'number' not described in 'update_outbnd_queue_table'
 drivers/scsi/pm8001/pm80xx_hwi.c:1717: warning: Function parameter or member 'vec' not described in 'pm80xx_chip_interrupt_enable'
 drivers/scsi/pm8001/pm80xx_hwi.c:1735: warning: Function parameter or member 'vec' not described in 'pm80xx_chip_interrupt_disable'
 drivers/scsi/pm8001/pm80xx_hwi.c:4830: warning: Excess function parameter 'num' description in 'pm80xx_chip_phy_start_req'
 drivers/scsi/pm8001/pm80xx_hwi.c:4872: warning: Excess function parameter 'num' description in 'pm80xx_chip_phy_stop_req'
 drivers/scsi/pm8001/pm80xx_hwi.c:4892: warning: Function parameter or member 'pm8001_ha' not described in 'pm80xx_chip_reg_dev_req'
 drivers/scsi/pm8001/pm80xx_hwi.c:4892: warning: Function parameter or member 'pm8001_dev' not described in 'pm80xx_chip_reg_dev_req'
 drivers/scsi/pm8001/pm80xx_hwi.c:4892: warning: Function parameter or member 'flag' not described in 'pm80xx_chip_reg_dev_req'
 drivers/scsi/pm8001/pm80xx_hwi.c:4966: warning: Function parameter or member 'phyId' not described in 'pm80xx_chip_phy_ctl_req'
 drivers/scsi/pm8001/pm80xx_hwi.c:4966: warning: Function parameter or member 'phy_op' not described in 'pm80xx_chip_phy_ctl_req'
 drivers/scsi/pm8001/pm80xx_hwi.c:4966: warning: Excess function parameter 'num' description in 'pm80xx_chip_phy_ctl_req'
 drivers/scsi/pm8001/pm80xx_hwi.c:4966: warning: Excess function parameter 'phy_id' description in 'pm80xx_chip_phy_ctl_req'
 drivers/scsi/pm8001/pm80xx_hwi.c:5006: warning: Function parameter or member 'vec' not described in 'pm80xx_chip_isr'
 drivers/scsi/pm8001/pm80xx_hwi.c:5006: warning: Excess function parameter 'irq' description in 'pm80xx_chip_isr'
 drivers/scsi/pm8001/pm80xx_hwi.c:5006: warning: Excess function parameter 'stat' description in 'pm80xx_chip_isr'

Link: https://lore.kernel.org/r/20200721164148.2617584-18-lee.jones@linaro.org
Cc: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.

In preparation for removing[2] the[3] macro[4], remove all remaining
needless uses with the following script:

git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \
	xargs perl -pi -e \
		's/\buninitialized_var\(([^\)]+)\)/\1/g;
		 s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;'

drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid
pathological white-space.

No outstanding warnings were found building allmodconfig with GCC 9.3.0
for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64,
alpha, and m68k.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/
[2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/
[3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/
[4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/

Reviewed-by: Leon Romanovsky <leonro@mellanox.com> # drivers/infiniband and mlx4/mlx5
Acked-by: Jason Gunthorpe <jgg@mellanox.com> # IB
Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless drivers
Reviewed-by: Chao Yu <yuchao0@huawei.com> # erofs
Signed-off-by: NKees Cook <keescook@chromium.org>

Added the sysfs attribute for non fatal log so that management utility can
get the non fatal dump from driver. The non-fatal error is an error
condition or abnormal behavior detected by the host, or detected and
reported by the controller to the host.The non-fatal error does not stop
the controller firmware and enables it to still respond to host requests.
A typical example of a non-fatal error is an I/O timeout or an unusual
error notification from the controller. Since the firmware is operational,
the error dump information is pushed to host memory (by firmware) upon
request from the host.

Link: https://lore.kernel.org/r/20200316074906.9119-6-deepak.ukey@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NDeepak Ukey <deepak.ukey@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

In pm80xx driver, the command mpi_set_phy_profile_req is sent by host
during boot to configure the phy profile such as analog setting page, rate
control page. However, the tag is not freed when its response is
received. As a result, 16 tags are missing for each HBA after boot.  When
NCQ is enabled with queue depth 16, it needs at least, 15 * 16 = 240 tags
for each HBA to achieve the best performance. In current pm80xx driver with
setting CCB_MAX = 256, the total number of tags in each HBA is 255 for data
IO. Hence, without returning those tags to the pool after boot, some device
will finally be forced to non-ncq mode by ATA layer due to excessive errors
(i.e. LLDD cannot allocate tag for queued task).

Link: https://lore.kernel.org/r/20200316074906.9119-4-deepak.ukey@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Nyuuzheng <yuuzheng@google.com>
Signed-off-by: NDeepak Ukey <deepak.ukey@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

A kexec reboot causes the controller fw to assert. This assertion shows up
in two ways, the controller doesn't show up as ready and an interrupt is
waiting as soon as the handler is registered. To resolve this added below
fix:

 - Split the interrupt handling setup into two parts, setup and request.

 - If the controller ready register indicates not-ready, but that the not
   readiness is only on the IOC units we can still try a reset to bring the
   system back to the pre-reboot state.

Link: https://lore.kernel.org/r/20200316074906.9119-3-deepak.ukey@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NVikram Auradkar <auradkar@google.com>
Signed-off-by: NDeepak Ukey <deepak.ukey@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

There is a spelling mistake in a pm8001_printk message. Fix it.

Link: https://lore.kernel.org/r/20200123005706.2834281-1-colin.king@canonical.comSigned-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Remove #include <linux/version.h>. Don't need it.

Link: https://lore.kernel.org/r/20191122020911.33269-1-yuehaibing@huawei.comSigned-off-by: NYueHaibing <yuehaibing@huawei.com>
Acked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The condition (reg_val != 2) || (reg_val != 3) will always be true because
reg_val cannot be equal to two different values at the same time. Fix this
by replacing the || operator with && so that the loop will loop if reg_val
is not a 2 and not a 3 as was originally intended.

Fixes: 50dc2f221455 ("scsi: pm80xx: Modified the logic to collect fatal dump")
Link: https://lore.kernel.org/r/20191120135031.270708-1-colin.king@canonical.com
Addresses-Coverity: ("Constant expression result")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>