[PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Damien Le Moal]

This series fix (remove) all sparse warnings generated when compiling
the mpt3sas driver. All warnings are related to __iomem access and
endianness.

The series was tested on top of Martin's 5.18/scsi-staging branch with a
9400-8i HBA with direct attached iSAS and SATA drives. The fixes need
careful review by the maintainers as there is no documentation clearly
explaning the proper endianness of the values touched.

Changes from v2:
* Reworked patch 5 to keep writel() calls. Sparse warnings are
  suppressed with a declaration fix.

Changes from v1:
* Reworked patch 1 to remove the TaskMID field type change and simplify
  _ctl_set_task_mid() code.

Damien Le Moal (5):
  scsi: mpt3sas: fix _ctl_set_task_mid() TaskMID check
  scsi: mpt3sas: Fix writel() use
  scsi: mpt3sas: fix ioc->base_readl() use
  scsi: mpt3sas: fix event callback log_code value handling
  scsi: mpt3sas: fix adapter replyPostRegisterIndex declaration

 drivers/scsi/mpt3sas/mpt3sas_base.c  | 32 ++++++++++++++--------------
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  2 +-
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   | 11 +++++-----
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |  6 +++---
 4 files changed, 26 insertions(+), 25 deletions(-)

-- 
2.35.1

[PATCH v3 1/5] scsi: mpt3sas: fix _ctl_set_task_mid() TaskMID check

[Damien Le Moal]

The TaskMID field of struct Mpi2SCSITaskManagementRequest_t is a 16-bits
little endian value. Fix the search loop in _ctl_set_task_mid() to add
a cpu_to_le16() conversion before checking the value of TaskMID to avoid
sparse warnings. While at it, simplify the search loop code to remove an
unnecessarily complicated if condition.

Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
---
 drivers/scsi/mpt3sas/mpt3sas_ctl.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index d92ca140d298..84c87c2c3e7e 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -578,7 +578,7 @@ static int
 _ctl_set_task_mid(struct MPT3SAS_ADAPTER *ioc, struct mpt3_ioctl_command *karg,
 	Mpi2SCSITaskManagementRequest_t *tm_request)
 {
-	u8 found = 0;
+	bool found = false;
 	u16 smid;
 	u16 handle;
 	struct scsi_cmnd *scmd;
@@ -600,6 +600,7 @@ _ctl_set_task_mid(struct MPT3SAS_ADAPTER *ioc, struct mpt3_ioctl_command *karg,
 	handle = le16_to_cpu(tm_request->DevHandle);
 	for (smid = ioc->scsiio_depth; smid && !found; smid--) {
 		struct scsiio_tracker *st;
+		__le16 task_mid;
 
 		scmd = mpt3sas_scsih_scsi_lookup_get(ioc, smid);
 		if (!scmd)
@@ -618,10 +619,10 @@ _ctl_set_task_mid(struct MPT3SAS_ADAPTER *ioc, struct mpt3_ioctl_command *karg,
 		 * first outstanding smid will be picked up.  Otherwise,
 		 * targeted smid will be the one.
 		 */
-		if (!tm_request->TaskMID || tm_request->TaskMID == st->smid) {
-			tm_request->TaskMID = cpu_to_le16(st->smid);
-			found = 1;
-		}
+		task_mid = cpu_to_le16(st->smid);
+		if (!tm_request->TaskMID)
+			tm_request->TaskMID = task_mid;
+		found = tm_request->TaskMID == task_mid;
 	}
 
 	if (!found) {
-- 
2.35.1

[PATCH v3 2/5] scsi: mpt3sas: Fix writel() use

[Damien Le Moal]

writel() internally execute cpu_to_le32() to convert the vale being
wrritten to little endian. The caller should thus not use this
conversion function for the value passed to writel(). Remove the
cpu_to_le32() calls in _base_put_smid_scsi_io_atomic(),
_base_put_smid_fast_path_atomic(), _base_put_smid_hi_priority_atomic()
_base_put_smid_default_atomic() amd _base_handshake_req_reply_wait().

Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 511726f92d9a..6ebdfedd84f5 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -4323,7 +4323,7 @@ _base_put_smid_scsi_io_atomic(struct MPT3SAS_ADAPTER *ioc, u16 smid,
 	descriptor.MSIxIndex = _base_set_and_get_msix_index(ioc, smid);
 	descriptor.SMID = cpu_to_le16(smid);
 
-	writel(cpu_to_le32(*request), &ioc->chip->AtomicRequestDescriptorPost);
+	writel(*request, &ioc->chip->AtomicRequestDescriptorPost);
 }
 
 /**
@@ -4345,7 +4345,7 @@ _base_put_smid_fast_path_atomic(struct MPT3SAS_ADAPTER *ioc, u16 smid,
 	descriptor.MSIxIndex = _base_set_and_get_msix_index(ioc, smid);
 	descriptor.SMID = cpu_to_le16(smid);
 
-	writel(cpu_to_le32(*request), &ioc->chip->AtomicRequestDescriptorPost);
+	writel(*request, &ioc->chip->AtomicRequestDescriptorPost);
 }
 
 /**
@@ -4368,7 +4368,7 @@ _base_put_smid_hi_priority_atomic(struct MPT3SAS_ADAPTER *ioc, u16 smid,
 	descriptor.MSIxIndex = msix_task;
 	descriptor.SMID = cpu_to_le16(smid);
 
-	writel(cpu_to_le32(*request), &ioc->chip->AtomicRequestDescriptorPost);
+	writel(*request, &ioc->chip->AtomicRequestDescriptorPost);
 }
 
 /**
@@ -4389,7 +4389,7 @@ _base_put_smid_default_atomic(struct MPT3SAS_ADAPTER *ioc, u16 smid)
 	descriptor.MSIxIndex = _base_set_and_get_msix_index(ioc, smid);
 	descriptor.SMID = cpu_to_le16(smid);
 
-	writel(cpu_to_le32(*request), &ioc->chip->AtomicRequestDescriptorPost);
+	writel(*request, &ioc->chip->AtomicRequestDescriptorPost);
 }
 
 /**
@@ -6906,7 +6906,7 @@ _base_handshake_req_reply_wait(struct MPT3SAS_ADAPTER *ioc, int request_bytes,
 
 	/* send message 32-bits at a time */
 	for (i = 0, failed = 0; i < request_bytes/4 && !failed; i++) {
-		writel(cpu_to_le32(request[i]), &ioc->chip->Doorbell);
+		writel(request[i], &ioc->chip->Doorbell);
 		if ((_base_wait_for_doorbell_ack(ioc, 5)))
 			failed = 1;
 	}
-- 
2.35.1

[PATCH v3 3/5] scsi: mpt3sas: fix ioc->base_readl() use

[Damien Le Moal]

The functions _base_readl_aero() and _base_readl() used for an adapter
base_readl() method are implemented using a regular readl() call which
performs internally a conversion to CPU endianness (le32_to_cpu()) of
the values read. The users of the ioc base_readl() method should thus
not convert again the values read using le16_to_cpu().
Fixing this removes sparse warnings.

Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 6ebdfedd84f5..5efe4bd186db 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -6925,16 +6925,16 @@ _base_handshake_req_reply_wait(struct MPT3SAS_ADAPTER *ioc, int request_bytes,
 	}
 
 	/* read the first two 16-bits, it gives the total length of the reply */
-	reply[0] = le16_to_cpu(ioc->base_readl(&ioc->chip->Doorbell)
-	    & MPI2_DOORBELL_DATA_MASK);
+	reply[0] = ioc->base_readl(&ioc->chip->Doorbell)
+		& MPI2_DOORBELL_DATA_MASK;
 	writel(0, &ioc->chip->HostInterruptStatus);
 	if ((_base_wait_for_doorbell_int(ioc, 5))) {
 		ioc_err(ioc, "doorbell handshake int failed (line=%d)\n",
 			__LINE__);
 		return -EFAULT;
 	}
-	reply[1] = le16_to_cpu(ioc->base_readl(&ioc->chip->Doorbell)
-	    & MPI2_DOORBELL_DATA_MASK);
+	reply[1] = ioc->base_readl(&ioc->chip->Doorbell)
+		& MPI2_DOORBELL_DATA_MASK;
 	writel(0, &ioc->chip->HostInterruptStatus);
 
 	for (i = 2; i < default_reply->MsgLength * 2; i++)  {
@@ -6946,9 +6946,8 @@ _base_handshake_req_reply_wait(struct MPT3SAS_ADAPTER *ioc, int request_bytes,
 		if (i >=  reply_bytes/2) /* overflow case */
 			ioc->base_readl(&ioc->chip->Doorbell);
 		else
-			reply[i] = le16_to_cpu(
-			    ioc->base_readl(&ioc->chip->Doorbell)
-			    & MPI2_DOORBELL_DATA_MASK);
+			reply[i] = ioc->base_readl(&ioc->chip->Doorbell)
+				& MPI2_DOORBELL_DATA_MASK;
 		writel(0, &ioc->chip->HostInterruptStatus);
 	}
 
-- 
2.35.1

[PATCH v3 4/5] scsi: mpt3sas: fix event callback log_code value handling

[Damien Le Moal]

In mpt3sas_scsih_event_callback(), fix a sparse warning when testing the
event log code value by replacing the use of a pointer to the address
storing the event log code with a log code local variable . Doing so,
le32_to_cpu() is used when the log code value is assigned, avoiding a
sparse warning.

Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 00792767c620..a355bc145577 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -10926,20 +10926,20 @@ mpt3sas_scsih_event_callback(struct MPT3SAS_ADAPTER *ioc, u8 msix_index,
 	case MPI2_EVENT_LOG_ENTRY_ADDED:
 	{
 		Mpi2EventDataLogEntryAdded_t *log_entry;
-		u32 *log_code;
+		u32 log_code;
 
 		if (!ioc->is_warpdrive)
 			break;
 
 		log_entry = (Mpi2EventDataLogEntryAdded_t *)
 		    mpi_reply->EventData;
-		log_code = (u32 *)log_entry->LogData;
+		log_code = le32_to_cpu(*(__le32 *)log_entry->LogData);
 
 		if (le16_to_cpu(log_entry->LogEntryQualifier)
 		    != MPT2_WARPDRIVE_LOGENTRY)
 			break;
 
-		switch (le32_to_cpu(*log_code)) {
+		switch (log_code) {
 		case MPT2_WARPDRIVE_LC_SSDT:
 			ioc_warn(ioc, "WarpDrive Warning: IO Throttling has occurred in the WarpDrive subsystem. Check WarpDrive documentation for additional details.\n");
 			break;
-- 
2.35.1

[PATCH v3 5/5] scsi: mpt3sas: fix adapter replyPostRegisterIndex declaration

[Damien Le Moal]

The replyPostRegisterIndex array of struct MPT3SAS_ADAPTER stores iomem
resource addresses. Fix its declaration to annotate it with __iomem to
avoid sparse warnings for writel() calls using the stored addresses.

Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 9 +++++----
 drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 5efe4bd186db..fa47f56c046f 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3703,10 +3703,11 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
 		}
 
 		for (i = 0; i < ioc->combined_reply_index_count; i++) {
-			ioc->replyPostRegisterIndex[i] = (resource_size_t *)
-			     ((u8 __force *)&ioc->chip->Doorbell +
-			     MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET +
-			     (i * MPT3_SUP_REPLY_POST_HOST_INDEX_REG_OFFSET));
+			ioc->replyPostRegisterIndex[i] =
+				(resource_size_t __iomem *)
+				((u8 __force *)&ioc->chip->Doorbell +
+				 MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET +
+				 (i * MPT3_SUP_REPLY_POST_HOST_INDEX_REG_OFFSET));
 		}
 	}
 
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 949e98d523e2..209f8680c01d 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -1588,7 +1588,7 @@ struct MPT3SAS_ADAPTER {
 	u8		combined_reply_index_count;
 	u8		smp_affinity_enable;
 	/* reply post register index */
-	resource_size_t	**replyPostRegisterIndex;
+	resource_size_t	__iomem **replyPostRegisterIndex;
 
 	struct list_head delayed_tr_list;
 	struct list_head delayed_tr_volume_list;
-- 
2.35.1

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Martin K. Petersen]

Sreekanth,

> This series fix (remove) all sparse warnings generated when compiling
> the mpt3sas driver. All warnings are related to __iomem access and
> endianness.

Please review this series and validate the patch 5 modification.

Thanks!

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Sreekanth Reddy]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Wed, Mar 9, 2022 at 9:26 AM Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>
>
> Sreekanth,
>
> > This series fix (remove) all sparse warnings generated when compiling
> > the mpt3sas driver. All warnings are related to __iomem access and
> > endianness.
>
> Please review this series and validate the patch 5 modification.

Martin,
This patch set looks good, but before acknowledging this patch set I
just wanted to do some basic testing on a big endian machine.
Currently I don't have a big endian machine, internally I am checking
to get access to big endian machines. Meanwhile if anyone does a basic
testing on any big endian machine then please let me know. I will add
the acknowledgement signature.

Thanks,
Sreekanth

>
> Thanks!
>
> --
> Martin K. Petersen      Oracle Linux Engineering

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4218 bytes --]

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Damien Le Moal]

On 3/8/22 08:48, Damien Le Moal wrote:
> This series fix (remove) all sparse warnings generated when compiling
> the mpt3sas driver. All warnings are related to __iomem access and
> endianness.
> 
> The series was tested on top of Martin's 5.18/scsi-staging branch with a
> 9400-8i HBA with direct attached iSAS and SATA drives. The fixes need
> careful review by the maintainers as there is no documentation clearly
> explaning the proper endianness of the values touched.

Martin,

Can we get this one queued for 5.19 ?

> 
> Changes from v2:
> * Reworked patch 5 to keep writel() calls. Sparse warnings are
>   suppressed with a declaration fix.
> 
> Changes from v1:
> * Reworked patch 1 to remove the TaskMID field type change and simplify
>   _ctl_set_task_mid() code.
> 
> Damien Le Moal (5):
>   scsi: mpt3sas: fix _ctl_set_task_mid() TaskMID check
>   scsi: mpt3sas: Fix writel() use
>   scsi: mpt3sas: fix ioc->base_readl() use
>   scsi: mpt3sas: fix event callback log_code value handling
>   scsi: mpt3sas: fix adapter replyPostRegisterIndex declaration
> 
>  drivers/scsi/mpt3sas/mpt3sas_base.c  | 32 ++++++++++++++--------------
>  drivers/scsi/mpt3sas/mpt3sas_base.h  |  2 +-
>  drivers/scsi/mpt3sas/mpt3sas_ctl.c   | 11 +++++-----
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |  6 +++---
>  4 files changed, 26 insertions(+), 25 deletions(-)
> 


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Martin K. Petersen]

Damien,

> Can we get this one queued for 5.19 ?

It's already in scsi-staging. Had some mail problems so not all merge
notifications went out.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Damien Le Moal]

On 4/26/22 19:37, Martin K. Petersen wrote:
> 
> Damien,
> 
>> Can we get this one queued for 5.19 ?
> 
> It's already in scsi-staging. Had some mail problems so not all merge
> notifications went out.
> 

OK. Thanks !

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Martin K. Petersen]

On Tue, 8 Mar 2022 08:48:49 +0900, Damien Le Moal wrote:

> This series fix (remove) all sparse warnings generated when compiling
> the mpt3sas driver. All warnings are related to __iomem access and
> endianness.
> 
> The series was tested on top of Martin's 5.18/scsi-staging branch with a
> 9400-8i HBA with direct attached iSAS and SATA drives. The fixes need
> careful review by the maintainers as there is no documentation clearly
> explaning the proper endianness of the values touched.
> 
> [...]

Applied to 5.19/scsi-queue, thanks!

[1/5] scsi: mpt3sas: fix _ctl_set_task_mid() TaskMID check
      https://git.kernel.org/mkp/scsi/c/dceaef94a475
[2/5] scsi: mpt3sas: Fix writel() use
      https://git.kernel.org/mkp/scsi/c/b4efbec4c2a7
[3/5] scsi: mpt3sas: fix ioc->base_readl() use
      https://git.kernel.org/mkp/scsi/c/7ab4d2441b95
[4/5] scsi: mpt3sas: fix event callback log_code value handling
      https://git.kernel.org/mkp/scsi/c/82b4420c288c
[5/5] scsi: mpt3sas: fix adapter replyPostRegisterIndex declaration
      https://git.kernel.org/mkp/scsi/c/fe413ab32b24

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[matoro]

Hi folks, sorry for the lateness, unfortunately this is in fact broken 
on BE.  I use mpt3sas on sparc and my drives fail to come up on 5.19, 
bisected to this patchset.  Reverting both of the endian-related 
commits, b4efbec4c2a75b619fae4e8768be379e88c78687 and 
7ab4d2441b952977556672c2fe3f4c2a698cbb37, allows it to boot.  However, 
after booting, I can't load any modules - everything errors with 
"disagrees about version of symbol module_layout".  I have completely 
wiped out kernel sources, the module tree, and the kernel image, 
rebuilding both from scratch with ONLY the revert patch applied, but I 
still can't load any modules.  Presumably it would work with 
CONFIG_MODVERSIONS=n, but these CRC checks are there for a reason and I 
can't tell if it has something to do with the revert or not.

$ modprobe --dump-modversions 
/lib/modules/5.19.0-gentoo-sparc64/kernel/fs/openpromfs/openpromfs.ko  | 
grep "module_layout"
0xa6c23707      module_layout
$ grep "module_layout" /usr/src/linux/Module.symvers
0xa6c23707      module_layout   vmlinux EXPORT_SYMBOL

If you need real hardware access and do not have any on hand, please 
reach out and I can provide temporary access!

Here is the full error on vanilla 5.19:

mpt3sas version 42.100.00.00 loaded
mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem 
(32650280 kB)
mpt2sas_cm0: _base_wait_for_doorbell_not_used: failed due to timeout 
count(5000), doorbell_reg(18000000)!
mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size to 
4k
mpt2sas_cm0: MSI-X vectors supported: 1
          no of cores: 64, max_msix_vectors: -1
mpt2sas_cm0:  0 1 1
mpt2sas_cm0: pci_alloc_irq_vectors failed (r=-22) !!!
mpt2sas_cm0: High IOPs queues : disabled
mpt2sas0: IO-APIC enabled: IRQ 4
mpt2sas_cm0: iomem(0x0000084100000000), mapped(0x(____ptrval____)), 
size(16384)
mpt2sas_cm0: ioport(0x0000085100000000), size(256)
mpt2sas_cm0: doorbell is in use (line=6869)
mpt2sas_cm0: _base_get_ioc_facts: handshake failed (r=-14)
mpt2sas_cm0: failure at 
drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
mpt2sas_cm1: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem 
(32650280 kB)
mpt2sas_cm1: _base_wait_for_doorbell_not_used: failed due to timeout 
count(5000), doorbell_reg(18000000)!
mpt2sas_cm1: CurrentHostPageSize is 0: Setting default host page size to 
4k
mpt2sas_cm1: MSI-X vectors supported: 1
          no of cores: 64, max_msix_vectors: -1
mpt2sas_cm1:  0 1 1
mpt2sas_cm1: pci_alloc_irq_vectors failed (r=-22) !!!
mpt2sas_cm1: High IOPs queues : disabled
mpt2sas1: IO-APIC enabled: IRQ 5
mpt2sas_cm1: iomem(0x0000084120000000), mapped(0x(____ptrval____)), 
size(16384)
mpt2sas_cm1: ioport(0x0000085100002000), size(256)
mpt2sas_cm1: doorbell is in use (line=6869)
mpt2sas_cm1: _base_get_ioc_facts: handshake failed (r=-14)
mpt2sas_cm1: failure at 
drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!

-------- Original Message --------
Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
Date: 2022-03-09 01:35
 From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>

On Wed, Mar 9, 2022 at 9:26 AM Martin K. Petersen
<martin.petersen@oracle.com> wrote:
> 
> 
> Sreekanth,
> 
> > This series fix (remove) all sparse warnings generated when compiling
> > the mpt3sas driver. All warnings are related to __iomem access and
> > endianness.
> 
> Please review this series and validate the patch 5 modification.

Martin,
This patch set looks good, but before acknowledging this patch set I
just wanted to do some basic testing on a big endian machine.
Currently I don't have a big endian machine, internally I am checking
to get access to big endian machines. Meanwhile if anyone does a basic
testing on any big endian machine then please let me know. I will add
the acknowledgement signature.

Thanks,
Sreekanth

> 
> Thanks!
> 
> --
> Martin K. Petersen      Oracle Linux Engineering

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Damien Le Moal]

On 8/3/22 05:27, matoro wrote:
> Hi folks, sorry for the lateness, unfortunately this is in fact broken 
> on BE.  I use mpt3sas on sparc and my drives fail to come up on 5.19, 
> bisected to this patchset.  Reverting both of the endian-related 
> commits, b4efbec4c2a75b619fae4e8768be379e88c78687 and 
> 7ab4d2441b952977556672c2fe3f4c2a698cbb37, allows it to boot.  However, 
> after booting, I can't load any modules - everything errors with 
> "disagrees about version of symbol module_layout".  I have completely 
> wiped out kernel sources, the module tree, and the kernel image, 
> rebuilding both from scratch with ONLY the revert patch applied, but I 
> still can't load any modules.  Presumably it would work with 
> CONFIG_MODVERSIONS=n, but these CRC checks are there for a reason and I 
> can't tell if it has something to do with the revert or not.

For b4efbec4c2a75b619fae4e8768be379e88c78687, removing the cpu_to_le32()
call results in the bytes actually being reversed by writel()/readl() for
your BE machine. So it looks like the values that need to be written to
the HBA have to be in CPU endian, not le32. Should be easy to fix.
And for 7ab4d2441b952977556672c2fe3f4c2a698cbb37, this looks like the same
problem.

I will be traveling and busy this week, but I can have a look at a fix
next Monday. If the Broadcom folks can send a fix faster than that, that
is of course welcome :)

> 
> $ modprobe --dump-modversions 
> /lib/modules/5.19.0-gentoo-sparc64/kernel/fs/openpromfs/openpromfs.ko  | 
> grep "module_layout"
> 0xa6c23707      module_layout
> $ grep "module_layout" /usr/src/linux/Module.symvers
> 0xa6c23707      module_layout   vmlinux EXPORT_SYMBOL
> 
> If you need real hardware access and do not have any on hand, please 
> reach out and I can provide temporary access!
> 
> Here is the full error on vanilla 5.19:
> 
> mpt3sas version 42.100.00.00 loaded
> mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem 
> (32650280 kB)
> mpt2sas_cm0: _base_wait_for_doorbell_not_used: failed due to timeout 
> count(5000), doorbell_reg(18000000)!
> mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size to 
> 4k
> mpt2sas_cm0: MSI-X vectors supported: 1
>           no of cores: 64, max_msix_vectors: -1
> mpt2sas_cm0:  0 1 1
> mpt2sas_cm0: pci_alloc_irq_vectors failed (r=-22) !!!
> mpt2sas_cm0: High IOPs queues : disabled
> mpt2sas0: IO-APIC enabled: IRQ 4
> mpt2sas_cm0: iomem(0x0000084100000000), mapped(0x(____ptrval____)), 
> size(16384)
> mpt2sas_cm0: ioport(0x0000085100000000), size(256)
> mpt2sas_cm0: doorbell is in use (line=6869)
> mpt2sas_cm0: _base_get_ioc_facts: handshake failed (r=-14)
> mpt2sas_cm0: failure at 
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
> mpt2sas_cm1: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem 
> (32650280 kB)
> mpt2sas_cm1: _base_wait_for_doorbell_not_used: failed due to timeout 
> count(5000), doorbell_reg(18000000)!
> mpt2sas_cm1: CurrentHostPageSize is 0: Setting default host page size to 
> 4k
> mpt2sas_cm1: MSI-X vectors supported: 1
>           no of cores: 64, max_msix_vectors: -1
> mpt2sas_cm1:  0 1 1
> mpt2sas_cm1: pci_alloc_irq_vectors failed (r=-22) !!!
> mpt2sas_cm1: High IOPs queues : disabled
> mpt2sas1: IO-APIC enabled: IRQ 5
> mpt2sas_cm1: iomem(0x0000084120000000), mapped(0x(____ptrval____)), 
> size(16384)
> mpt2sas_cm1: ioport(0x0000085100002000), size(256)
> mpt2sas_cm1: doorbell is in use (line=6869)
> mpt2sas_cm1: _base_get_ioc_facts: handshake failed (r=-14)
> mpt2sas_cm1: failure at 
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
> 
> -------- Original Message --------
> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
> Date: 2022-03-09 01:35
>  From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
> To: "Martin K. Petersen" <martin.petersen@oracle.com>
> 
> On Wed, Mar 9, 2022 at 9:26 AM Martin K. Petersen
> <martin.petersen@oracle.com> wrote:
>>
>>
>> Sreekanth,
>>
>>> This series fix (remove) all sparse warnings generated when compiling
>>> the mpt3sas driver. All warnings are related to __iomem access and
>>> endianness.
>>
>> Please review this series and validate the patch 5 modification.
> 
> Martin,
> This patch set looks good, but before acknowledging this patch set I
> just wanted to do some basic testing on a big endian machine.
> Currently I don't have a big endian machine, internally I am checking
> to get access to big endian machines. Meanwhile if anyone does a basic
> testing on any big endian machine then please let me know. I will add
> the acknowledgement signature.
> 
> Thanks,
> Sreekanth
> 
>>
>> Thanks!
>>
>> --
>> Martin K. Petersen      Oracle Linux Engineering


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[matoro]

Just a small update, the module stuff turned out to be a separate, 
unrelated regression.  I bisected that one also (applying these reverts 
each time to allow me to boot) and reported it to Masahiro, who put in a 
fix for it here:  
https://lore.kernel.org/all/20220809141117.641543-1-masahiroy@kernel.org/ 
.  So you can ignore that stuff.  Are these two commits still planned to 
be reverted?

-------- Original Message --------
Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
Date: 2022-08-02 19:36
 From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: matoro <matoro_mailinglist_kernel@matoro.tk>, Sreekanth Reddy 
<sreekanth.reddy@broadcom.com>

On 8/3/22 05:27, matoro wrote:
> Hi folks, sorry for the lateness, unfortunately this is in fact broken
> on BE.  I use mpt3sas on sparc and my drives fail to come up on 5.19,
> bisected to this patchset.  Reverting both of the endian-related
> commits, b4efbec4c2a75b619fae4e8768be379e88c78687 and
> 7ab4d2441b952977556672c2fe3f4c2a698cbb37, allows it to boot.  However,
> after booting, I can't load any modules - everything errors with
> "disagrees about version of symbol module_layout".  I have completely
> wiped out kernel sources, the module tree, and the kernel image,
> rebuilding both from scratch with ONLY the revert patch applied, but I
> still can't load any modules.  Presumably it would work with
> CONFIG_MODVERSIONS=n, but these CRC checks are there for a reason and I
> can't tell if it has something to do with the revert or not.

For b4efbec4c2a75b619fae4e8768be379e88c78687, removing the cpu_to_le32()
call results in the bytes actually being reversed by writel()/readl() 
for
your BE machine. So it looks like the values that need to be written to
the HBA have to be in CPU endian, not le32. Should be easy to fix.
And for 7ab4d2441b952977556672c2fe3f4c2a698cbb37, this looks like the 
same
problem.

I will be traveling and busy this week, but I can have a look at a fix
next Monday. If the Broadcom folks can send a fix faster than that, that
is of course welcome :)

> 
> $ modprobe --dump-modversions
> /lib/modules/5.19.0-gentoo-sparc64/kernel/fs/openpromfs/openpromfs.ko  
> |
> grep "module_layout"
> 0xa6c23707      module_layout
> $ grep "module_layout" /usr/src/linux/Module.symvers
> 0xa6c23707      module_layout   vmlinux EXPORT_SYMBOL
> 
> If you need real hardware access and do not have any on hand, please
> reach out and I can provide temporary access!
> 
> Here is the full error on vanilla 5.19:
> 
> mpt3sas version 42.100.00.00 loaded
> mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
> (32650280 kB)
> mpt2sas_cm0: _base_wait_for_doorbell_not_used: failed due to timeout
> count(5000), doorbell_reg(18000000)!
> mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size 
> to
> 4k
> mpt2sas_cm0: MSI-X vectors supported: 1
>           no of cores: 64, max_msix_vectors: -1
> mpt2sas_cm0:  0 1 1
> mpt2sas_cm0: pci_alloc_irq_vectors failed (r=-22) !!!
> mpt2sas_cm0: High IOPs queues : disabled
> mpt2sas0: IO-APIC enabled: IRQ 4
> mpt2sas_cm0: iomem(0x0000084100000000), mapped(0x(____ptrval____)),
> size(16384)
> mpt2sas_cm0: ioport(0x0000085100000000), size(256)
> mpt2sas_cm0: doorbell is in use (line=6869)
> mpt2sas_cm0: _base_get_ioc_facts: handshake failed (r=-14)
> mpt2sas_cm0: failure at
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
> mpt2sas_cm1: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
> (32650280 kB)
> mpt2sas_cm1: _base_wait_for_doorbell_not_used: failed due to timeout
> count(5000), doorbell_reg(18000000)!
> mpt2sas_cm1: CurrentHostPageSize is 0: Setting default host page size 
> to
> 4k
> mpt2sas_cm1: MSI-X vectors supported: 1
>           no of cores: 64, max_msix_vectors: -1
> mpt2sas_cm1:  0 1 1
> mpt2sas_cm1: pci_alloc_irq_vectors failed (r=-22) !!!
> mpt2sas_cm1: High IOPs queues : disabled
> mpt2sas1: IO-APIC enabled: IRQ 5
> mpt2sas_cm1: iomem(0x0000084120000000), mapped(0x(____ptrval____)),
> size(16384)
> mpt2sas_cm1: ioport(0x0000085100002000), size(256)
> mpt2sas_cm1: doorbell is in use (line=6869)
> mpt2sas_cm1: _base_get_ioc_facts: handshake failed (r=-14)
> mpt2sas_cm1: failure at
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
> 
> -------- Original Message --------
> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
> Date: 2022-03-09 01:35
>  From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
> To: "Martin K. Petersen" <martin.petersen@oracle.com>
> 
> On Wed, Mar 9, 2022 at 9:26 AM Martin K. Petersen
> <martin.petersen@oracle.com> wrote:
>> 
>> 
>> Sreekanth,
>> 
>>> This series fix (remove) all sparse warnings generated when compiling
>>> the mpt3sas driver. All warnings are related to __iomem access and
>>> endianness.
>> 
>> Please review this series and validate the patch 5 modification.
> 
> Martin,
> This patch set looks good, but before acknowledging this patch set I
> just wanted to do some basic testing on a big endian machine.
> Currently I don't have a big endian machine, internally I am checking
> to get access to big endian machines. Meanwhile if anyone does a basic
> testing on any big endian machine then please let me know. I will add
> the acknowledgement signature.
> 
> Thanks,
> Sreekanth
> 
>> 
>> Thanks!
>> 
>> --
>> Martin K. Petersen      Oracle Linux Engineering

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Damien Le Moal]

On 2022/08/11 12:05, matoro wrote:
> Just a small update, the module stuff turned out to be a separate, 
> unrelated regression.  I bisected that one also (applying these reverts 
> each time to allow me to boot) and reported it to Masahiro, who put in a 
> fix for it here:  
> https://lore.kernel.org/all/20220809141117.641543-1-masahiroy@kernel.org/ 
> .  So you can ignore that stuff.  Are these two commits still planned to 
> be reverted?

Revert should be a last resort (I really want to get rid of all these sparse
warnings !). Let me first try to generate a fix for you to test.

> 
> -------- Original Message --------
> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
> Date: 2022-08-02 19:36
>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
> To: matoro <matoro_mailinglist_kernel@matoro.tk>, Sreekanth Reddy 
> <sreekanth.reddy@broadcom.com>
> 
> On 8/3/22 05:27, matoro wrote:
>> Hi folks, sorry for the lateness, unfortunately this is in fact broken
>> on BE.  I use mpt3sas on sparc and my drives fail to come up on 5.19,
>> bisected to this patchset.  Reverting both of the endian-related
>> commits, b4efbec4c2a75b619fae4e8768be379e88c78687 and
>> 7ab4d2441b952977556672c2fe3f4c2a698cbb37, allows it to boot.  However,
>> after booting, I can't load any modules - everything errors with
>> "disagrees about version of symbol module_layout".  I have completely
>> wiped out kernel sources, the module tree, and the kernel image,
>> rebuilding both from scratch with ONLY the revert patch applied, but I
>> still can't load any modules.  Presumably it would work with
>> CONFIG_MODVERSIONS=n, but these CRC checks are there for a reason and I
>> can't tell if it has something to do with the revert or not.
> 
> For b4efbec4c2a75b619fae4e8768be379e88c78687, removing the cpu_to_le32()
> call results in the bytes actually being reversed by writel()/readl() 
> for
> your BE machine. So it looks like the values that need to be written to
> the HBA have to be in CPU endian, not le32. Should be easy to fix.
> And for 7ab4d2441b952977556672c2fe3f4c2a698cbb37, this looks like the 
> same
> problem.
> 
> I will be traveling and busy this week, but I can have a look at a fix
> next Monday. If the Broadcom folks can send a fix faster than that, that
> is of course welcome :)
> 
>>
>> $ modprobe --dump-modversions
>> /lib/modules/5.19.0-gentoo-sparc64/kernel/fs/openpromfs/openpromfs.ko  
>> |
>> grep "module_layout"
>> 0xa6c23707      module_layout
>> $ grep "module_layout" /usr/src/linux/Module.symvers
>> 0xa6c23707      module_layout   vmlinux EXPORT_SYMBOL
>>
>> If you need real hardware access and do not have any on hand, please
>> reach out and I can provide temporary access!
>>
>> Here is the full error on vanilla 5.19:
>>
>> mpt3sas version 42.100.00.00 loaded
>> mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>> (32650280 kB)
>> mpt2sas_cm0: _base_wait_for_doorbell_not_used: failed due to timeout
>> count(5000), doorbell_reg(18000000)!
>> mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size 
>> to
>> 4k
>> mpt2sas_cm0: MSI-X vectors supported: 1
>>           no of cores: 64, max_msix_vectors: -1
>> mpt2sas_cm0:  0 1 1
>> mpt2sas_cm0: pci_alloc_irq_vectors failed (r=-22) !!!
>> mpt2sas_cm0: High IOPs queues : disabled
>> mpt2sas0: IO-APIC enabled: IRQ 4
>> mpt2sas_cm0: iomem(0x0000084100000000), mapped(0x(____ptrval____)),
>> size(16384)
>> mpt2sas_cm0: ioport(0x0000085100000000), size(256)
>> mpt2sas_cm0: doorbell is in use (line=6869)
>> mpt2sas_cm0: _base_get_ioc_facts: handshake failed (r=-14)
>> mpt2sas_cm0: failure at
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>> mpt2sas_cm1: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>> (32650280 kB)
>> mpt2sas_cm1: _base_wait_for_doorbell_not_used: failed due to timeout
>> count(5000), doorbell_reg(18000000)!
>> mpt2sas_cm1: CurrentHostPageSize is 0: Setting default host page size 
>> to
>> 4k
>> mpt2sas_cm1: MSI-X vectors supported: 1
>>           no of cores: 64, max_msix_vectors: -1
>> mpt2sas_cm1:  0 1 1
>> mpt2sas_cm1: pci_alloc_irq_vectors failed (r=-22) !!!
>> mpt2sas_cm1: High IOPs queues : disabled
>> mpt2sas1: IO-APIC enabled: IRQ 5
>> mpt2sas_cm1: iomem(0x0000084120000000), mapped(0x(____ptrval____)),
>> size(16384)
>> mpt2sas_cm1: ioport(0x0000085100002000), size(256)
>> mpt2sas_cm1: doorbell is in use (line=6869)
>> mpt2sas_cm1: _base_get_ioc_facts: handshake failed (r=-14)
>> mpt2sas_cm1: failure at
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>>
>> -------- Original Message --------
>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>> Date: 2022-03-09 01:35
>>  From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
>> To: "Martin K. Petersen" <martin.petersen@oracle.com>
>>
>> On Wed, Mar 9, 2022 at 9:26 AM Martin K. Petersen
>> <martin.petersen@oracle.com> wrote:
>>>
>>>
>>> Sreekanth,
>>>
>>>> This series fix (remove) all sparse warnings generated when compiling
>>>> the mpt3sas driver. All warnings are related to __iomem access and
>>>> endianness.
>>>
>>> Please review this series and validate the patch 5 modification.
>>
>> Martin,
>> This patch set looks good, but before acknowledging this patch set I
>> just wanted to do some basic testing on a big endian machine.
>> Currently I don't have a big endian machine, internally I am checking
>> to get access to big endian machines. Meanwhile if anyone does a basic
>> testing on any big endian machine then please let me know. I will add
>> the acknowledgement signature.
>>
>> Thanks,
>> Sreekanth
>>
>>>
>>> Thanks!
>>>
>>> --
>>> Martin K. Petersen      Oracle Linux Engineering
> 


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[matoro]

Hi Damien, were you able to put together a fix to test?  We're up to 
5.19.3 now and 5.18 was just marked EOL, so I want to make sure this 
doesn't drop off the radar.

-------- Original Message --------
Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
Date: 2022-08-11 15:17
 From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: matoro <matoro_mailinglist_kernel@matoro.tk>

On 2022/08/11 12:05, matoro wrote:
> Just a small update, the module stuff turned out to be a separate,
> unrelated regression.  I bisected that one also (applying these reverts
> each time to allow me to boot) and reported it to Masahiro, who put in 
> a
> fix for it here:
> https://lore.kernel.org/all/20220809141117.641543-1-masahiroy@kernel.org/
> .  So you can ignore that stuff.  Are these two commits still planned 
> to
> be reverted?

Revert should be a last resort (I really want to get rid of all these 
sparse
warnings !). Let me first try to generate a fix for you to test.

> 
> -------- Original Message --------
> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
> Date: 2022-08-02 19:36
>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
> To: matoro <matoro_mailinglist_kernel@matoro.tk>, Sreekanth Reddy
> <sreekanth.reddy@broadcom.com>
> 
> On 8/3/22 05:27, matoro wrote:
>> Hi folks, sorry for the lateness, unfortunately this is in fact broken
>> on BE.  I use mpt3sas on sparc and my drives fail to come up on 5.19,
>> bisected to this patchset.  Reverting both of the endian-related
>> commits, b4efbec4c2a75b619fae4e8768be379e88c78687 and
>> 7ab4d2441b952977556672c2fe3f4c2a698cbb37, allows it to boot.  However,
>> after booting, I can't load any modules - everything errors with
>> "disagrees about version of symbol module_layout".  I have completely
>> wiped out kernel sources, the module tree, and the kernel image,
>> rebuilding both from scratch with ONLY the revert patch applied, but I
>> still can't load any modules.  Presumably it would work with
>> CONFIG_MODVERSIONS=n, but these CRC checks are there for a reason and 
>> I
>> can't tell if it has something to do with the revert or not.
> 
> For b4efbec4c2a75b619fae4e8768be379e88c78687, removing the 
> cpu_to_le32()
> call results in the bytes actually being reversed by writel()/readl()
> for
> your BE machine. So it looks like the values that need to be written to
> the HBA have to be in CPU endian, not le32. Should be easy to fix.
> And for 7ab4d2441b952977556672c2fe3f4c2a698cbb37, this looks like the
> same
> problem.
> 
> I will be traveling and busy this week, but I can have a look at a fix
> next Monday. If the Broadcom folks can send a fix faster than that, 
> that
> is of course welcome :)
> 
>> 
>> $ modprobe --dump-modversions
>> /lib/modules/5.19.0-gentoo-sparc64/kernel/fs/openpromfs/openpromfs.ko
>> |
>> grep "module_layout"
>> 0xa6c23707      module_layout
>> $ grep "module_layout" /usr/src/linux/Module.symvers
>> 0xa6c23707      module_layout   vmlinux EXPORT_SYMBOL
>> 
>> If you need real hardware access and do not have any on hand, please
>> reach out and I can provide temporary access!
>> 
>> Here is the full error on vanilla 5.19:
>> 
>> mpt3sas version 42.100.00.00 loaded
>> mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>> (32650280 kB)
>> mpt2sas_cm0: _base_wait_for_doorbell_not_used: failed due to timeout
>> count(5000), doorbell_reg(18000000)!
>> mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size
>> to
>> 4k
>> mpt2sas_cm0: MSI-X vectors supported: 1
>>           no of cores: 64, max_msix_vectors: -1
>> mpt2sas_cm0:  0 1 1
>> mpt2sas_cm0: pci_alloc_irq_vectors failed (r=-22) !!!
>> mpt2sas_cm0: High IOPs queues : disabled
>> mpt2sas0: IO-APIC enabled: IRQ 4
>> mpt2sas_cm0: iomem(0x0000084100000000), mapped(0x(____ptrval____)),
>> size(16384)
>> mpt2sas_cm0: ioport(0x0000085100000000), size(256)
>> mpt2sas_cm0: doorbell is in use (line=6869)
>> mpt2sas_cm0: _base_get_ioc_facts: handshake failed (r=-14)
>> mpt2sas_cm0: failure at
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>> mpt2sas_cm1: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>> (32650280 kB)
>> mpt2sas_cm1: _base_wait_for_doorbell_not_used: failed due to timeout
>> count(5000), doorbell_reg(18000000)!
>> mpt2sas_cm1: CurrentHostPageSize is 0: Setting default host page size
>> to
>> 4k
>> mpt2sas_cm1: MSI-X vectors supported: 1
>>           no of cores: 64, max_msix_vectors: -1
>> mpt2sas_cm1:  0 1 1
>> mpt2sas_cm1: pci_alloc_irq_vectors failed (r=-22) !!!
>> mpt2sas_cm1: High IOPs queues : disabled
>> mpt2sas1: IO-APIC enabled: IRQ 5
>> mpt2sas_cm1: iomem(0x0000084120000000), mapped(0x(____ptrval____)),
>> size(16384)
>> mpt2sas_cm1: ioport(0x0000085100002000), size(256)
>> mpt2sas_cm1: doorbell is in use (line=6869)
>> mpt2sas_cm1: _base_get_ioc_facts: handshake failed (r=-14)
>> mpt2sas_cm1: failure at
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>> 
>> -------- Original Message --------
>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>> Date: 2022-03-09 01:35
>>  From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
>> To: "Martin K. Petersen" <martin.petersen@oracle.com>
>> 
>> On Wed, Mar 9, 2022 at 9:26 AM Martin K. Petersen
>> <martin.petersen@oracle.com> wrote:
>>> 
>>> 
>>> Sreekanth,
>>> 
>>>> This series fix (remove) all sparse warnings generated when 
>>>> compiling
>>>> the mpt3sas driver. All warnings are related to __iomem access and
>>>> endianness.
>>> 
>>> Please review this series and validate the patch 5 modification.
>> 
>> Martin,
>> This patch set looks good, but before acknowledging this patch set I
>> just wanted to do some basic testing on a big endian machine.
>> Currently I don't have a big endian machine, internally I am checking
>> to get access to big endian machines. Meanwhile if anyone does a basic
>> testing on any big endian machine then please let me know. I will add
>> the acknowledgement signature.
>> 
>> Thanks,
>> Sreekanth
>> 
>>> 
>>> Thanks!
>>> 
>>> --
>>> Martin K. Petersen      Oracle Linux Engineering
> 

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Damien Le Moal]

On 2022/08/22 10:51, matoro wrote:
> Hi Damien, were you able to put together a fix to test?  We're up to 
> 5.19.3 now and 5.18 was just marked EOL, so I want to make sure this 
> doesn't drop off the radar.

No, sorry, I have been busy as I am traveling. Flying back home this week, so
likely will have more time next week.

> 
> -------- Original Message --------
> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
> Date: 2022-08-11 15:17
>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
> To: matoro <matoro_mailinglist_kernel@matoro.tk>
> 
> On 2022/08/11 12:05, matoro wrote:
>> Just a small update, the module stuff turned out to be a separate,
>> unrelated regression.  I bisected that one also (applying these reverts
>> each time to allow me to boot) and reported it to Masahiro, who put in 
>> a
>> fix for it here:
>> https://lore.kernel.org/all/20220809141117.641543-1-masahiroy@kernel.org/
>> .  So you can ignore that stuff.  Are these two commits still planned 
>> to
>> be reverted?
> 
> Revert should be a last resort (I really want to get rid of all these 
> sparse
> warnings !). Let me first try to generate a fix for you to test.
> 
>>
>> -------- Original Message --------
>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>> Date: 2022-08-02 19:36
>>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
>> To: matoro <matoro_mailinglist_kernel@matoro.tk>, Sreekanth Reddy
>> <sreekanth.reddy@broadcom.com>
>>
>> On 8/3/22 05:27, matoro wrote:
>>> Hi folks, sorry for the lateness, unfortunately this is in fact broken
>>> on BE.  I use mpt3sas on sparc and my drives fail to come up on 5.19,
>>> bisected to this patchset.  Reverting both of the endian-related
>>> commits, b4efbec4c2a75b619fae4e8768be379e88c78687 and
>>> 7ab4d2441b952977556672c2fe3f4c2a698cbb37, allows it to boot.  However,
>>> after booting, I can't load any modules - everything errors with
>>> "disagrees about version of symbol module_layout".  I have completely
>>> wiped out kernel sources, the module tree, and the kernel image,
>>> rebuilding both from scratch with ONLY the revert patch applied, but I
>>> still can't load any modules.  Presumably it would work with
>>> CONFIG_MODVERSIONS=n, but these CRC checks are there for a reason and 
>>> I
>>> can't tell if it has something to do with the revert or not.
>>
>> For b4efbec4c2a75b619fae4e8768be379e88c78687, removing the 
>> cpu_to_le32()
>> call results in the bytes actually being reversed by writel()/readl()
>> for
>> your BE machine. So it looks like the values that need to be written to
>> the HBA have to be in CPU endian, not le32. Should be easy to fix.
>> And for 7ab4d2441b952977556672c2fe3f4c2a698cbb37, this looks like the
>> same
>> problem.
>>
>> I will be traveling and busy this week, but I can have a look at a fix
>> next Monday. If the Broadcom folks can send a fix faster than that, 
>> that
>> is of course welcome :)
>>
>>>
>>> $ modprobe --dump-modversions
>>> /lib/modules/5.19.0-gentoo-sparc64/kernel/fs/openpromfs/openpromfs.ko
>>> |
>>> grep "module_layout"
>>> 0xa6c23707      module_layout
>>> $ grep "module_layout" /usr/src/linux/Module.symvers
>>> 0xa6c23707      module_layout   vmlinux EXPORT_SYMBOL
>>>
>>> If you need real hardware access and do not have any on hand, please
>>> reach out and I can provide temporary access!
>>>
>>> Here is the full error on vanilla 5.19:
>>>
>>> mpt3sas version 42.100.00.00 loaded
>>> mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>>> (32650280 kB)
>>> mpt2sas_cm0: _base_wait_for_doorbell_not_used: failed due to timeout
>>> count(5000), doorbell_reg(18000000)!
>>> mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size
>>> to
>>> 4k
>>> mpt2sas_cm0: MSI-X vectors supported: 1
>>>           no of cores: 64, max_msix_vectors: -1
>>> mpt2sas_cm0:  0 1 1
>>> mpt2sas_cm0: pci_alloc_irq_vectors failed (r=-22) !!!
>>> mpt2sas_cm0: High IOPs queues : disabled
>>> mpt2sas0: IO-APIC enabled: IRQ 4
>>> mpt2sas_cm0: iomem(0x0000084100000000), mapped(0x(____ptrval____)),
>>> size(16384)
>>> mpt2sas_cm0: ioport(0x0000085100000000), size(256)
>>> mpt2sas_cm0: doorbell is in use (line=6869)
>>> mpt2sas_cm0: _base_get_ioc_facts: handshake failed (r=-14)
>>> mpt2sas_cm0: failure at
>>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>>> mpt2sas_cm1: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>>> (32650280 kB)
>>> mpt2sas_cm1: _base_wait_for_doorbell_not_used: failed due to timeout
>>> count(5000), doorbell_reg(18000000)!
>>> mpt2sas_cm1: CurrentHostPageSize is 0: Setting default host page size
>>> to
>>> 4k
>>> mpt2sas_cm1: MSI-X vectors supported: 1
>>>           no of cores: 64, max_msix_vectors: -1
>>> mpt2sas_cm1:  0 1 1
>>> mpt2sas_cm1: pci_alloc_irq_vectors failed (r=-22) !!!
>>> mpt2sas_cm1: High IOPs queues : disabled
>>> mpt2sas1: IO-APIC enabled: IRQ 5
>>> mpt2sas_cm1: iomem(0x0000084120000000), mapped(0x(____ptrval____)),
>>> size(16384)
>>> mpt2sas_cm1: ioport(0x0000085100002000), size(256)
>>> mpt2sas_cm1: doorbell is in use (line=6869)
>>> mpt2sas_cm1: _base_get_ioc_facts: handshake failed (r=-14)
>>> mpt2sas_cm1: failure at
>>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>>>
>>> -------- Original Message --------
>>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>>> Date: 2022-03-09 01:35
>>>  From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
>>> To: "Martin K. Petersen" <martin.petersen@oracle.com>
>>>
>>> On Wed, Mar 9, 2022 at 9:26 AM Martin K. Petersen
>>> <martin.petersen@oracle.com> wrote:
>>>>
>>>>
>>>> Sreekanth,
>>>>
>>>>> This series fix (remove) all sparse warnings generated when 
>>>>> compiling
>>>>> the mpt3sas driver. All warnings are related to __iomem access and
>>>>> endianness.
>>>>
>>>> Please review this series and validate the patch 5 modification.
>>>
>>> Martin,
>>> This patch set looks good, but before acknowledging this patch set I
>>> just wanted to do some basic testing on a big endian machine.
>>> Currently I don't have a big endian machine, internally I am checking
>>> to get access to big endian machines. Meanwhile if anyone does a basic
>>> testing on any big endian machine then please let me know. I will add
>>> the acknowledgement signature.
>>>
>>> Thanks,
>>> Sreekanth
>>>
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Martin K. Petersen      Oracle Linux Engineering
>>
> 


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[matoro]

Hi Damien, apologies for continuing to bother.  Did you get a chance to 
put together a quick fix for this to test?

-------- Original Message --------
Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
Date: 2022-08-22 13:53
 From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: matoro <matoro_mailinglist_kernel@matoro.tk>

On 2022/08/22 10:51, matoro wrote:
> Hi Damien, were you able to put together a fix to test?  We're up to
> 5.19.3 now and 5.18 was just marked EOL, so I want to make sure this
> doesn't drop off the radar.

No, sorry, I have been busy as I am traveling. Flying back home this 
week, so
likely will have more time next week.

> 
> -------- Original Message --------
> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
> Date: 2022-08-11 15:17
>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
> To: matoro <matoro_mailinglist_kernel@matoro.tk>
> 
> On 2022/08/11 12:05, matoro wrote:
>> Just a small update, the module stuff turned out to be a separate,
>> unrelated regression.  I bisected that one also (applying these 
>> reverts
>> each time to allow me to boot) and reported it to Masahiro, who put in
>> a
>> fix for it here:
>> https://lore.kernel.org/all/20220809141117.641543-1-masahiroy@kernel.org/
>> .  So you can ignore that stuff.  Are these two commits still planned
>> to
>> be reverted?
> 
> Revert should be a last resort (I really want to get rid of all these
> sparse
> warnings !). Let me first try to generate a fix for you to test.
> 
>> 
>> -------- Original Message --------
>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>> Date: 2022-08-02 19:36
>>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
>> To: matoro <matoro_mailinglist_kernel@matoro.tk>, Sreekanth Reddy
>> <sreekanth.reddy@broadcom.com>
>> 
>> On 8/3/22 05:27, matoro wrote:
>>> Hi folks, sorry for the lateness, unfortunately this is in fact 
>>> broken
>>> on BE.  I use mpt3sas on sparc and my drives fail to come up on 5.19,
>>> bisected to this patchset.  Reverting both of the endian-related
>>> commits, b4efbec4c2a75b619fae4e8768be379e88c78687 and
>>> 7ab4d2441b952977556672c2fe3f4c2a698cbb37, allows it to boot.  
>>> However,
>>> after booting, I can't load any modules - everything errors with
>>> "disagrees about version of symbol module_layout".  I have completely
>>> wiped out kernel sources, the module tree, and the kernel image,
>>> rebuilding both from scratch with ONLY the revert patch applied, but 
>>> I
>>> still can't load any modules.  Presumably it would work with
>>> CONFIG_MODVERSIONS=n, but these CRC checks are there for a reason and
>>> I
>>> can't tell if it has something to do with the revert or not.
>> 
>> For b4efbec4c2a75b619fae4e8768be379e88c78687, removing the
>> cpu_to_le32()
>> call results in the bytes actually being reversed by writel()/readl()
>> for
>> your BE machine. So it looks like the values that need to be written 
>> to
>> the HBA have to be in CPU endian, not le32. Should be easy to fix.
>> And for 7ab4d2441b952977556672c2fe3f4c2a698cbb37, this looks like the
>> same
>> problem.
>> 
>> I will be traveling and busy this week, but I can have a look at a fix
>> next Monday. If the Broadcom folks can send a fix faster than that,
>> that
>> is of course welcome :)
>> 
>>> 
>>> $ modprobe --dump-modversions
>>> /lib/modules/5.19.0-gentoo-sparc64/kernel/fs/openpromfs/openpromfs.ko
>>> |
>>> grep "module_layout"
>>> 0xa6c23707      module_layout
>>> $ grep "module_layout" /usr/src/linux/Module.symvers
>>> 0xa6c23707      module_layout   vmlinux EXPORT_SYMBOL
>>> 
>>> If you need real hardware access and do not have any on hand, please
>>> reach out and I can provide temporary access!
>>> 
>>> Here is the full error on vanilla 5.19:
>>> 
>>> mpt3sas version 42.100.00.00 loaded
>>> mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>>> (32650280 kB)
>>> mpt2sas_cm0: _base_wait_for_doorbell_not_used: failed due to timeout
>>> count(5000), doorbell_reg(18000000)!
>>> mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size
>>> to
>>> 4k
>>> mpt2sas_cm0: MSI-X vectors supported: 1
>>>           no of cores: 64, max_msix_vectors: -1
>>> mpt2sas_cm0:  0 1 1
>>> mpt2sas_cm0: pci_alloc_irq_vectors failed (r=-22) !!!
>>> mpt2sas_cm0: High IOPs queues : disabled
>>> mpt2sas0: IO-APIC enabled: IRQ 4
>>> mpt2sas_cm0: iomem(0x0000084100000000), mapped(0x(____ptrval____)),
>>> size(16384)
>>> mpt2sas_cm0: ioport(0x0000085100000000), size(256)
>>> mpt2sas_cm0: doorbell is in use (line=6869)
>>> mpt2sas_cm0: _base_get_ioc_facts: handshake failed (r=-14)
>>> mpt2sas_cm0: failure at
>>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>>> mpt2sas_cm1: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>>> (32650280 kB)
>>> mpt2sas_cm1: _base_wait_for_doorbell_not_used: failed due to timeout
>>> count(5000), doorbell_reg(18000000)!
>>> mpt2sas_cm1: CurrentHostPageSize is 0: Setting default host page size
>>> to
>>> 4k
>>> mpt2sas_cm1: MSI-X vectors supported: 1
>>>           no of cores: 64, max_msix_vectors: -1
>>> mpt2sas_cm1:  0 1 1
>>> mpt2sas_cm1: pci_alloc_irq_vectors failed (r=-22) !!!
>>> mpt2sas_cm1: High IOPs queues : disabled
>>> mpt2sas1: IO-APIC enabled: IRQ 5
>>> mpt2sas_cm1: iomem(0x0000084120000000), mapped(0x(____ptrval____)),
>>> size(16384)
>>> mpt2sas_cm1: ioport(0x0000085100002000), size(256)
>>> mpt2sas_cm1: doorbell is in use (line=6869)
>>> mpt2sas_cm1: _base_get_ioc_facts: handshake failed (r=-14)
>>> mpt2sas_cm1: failure at
>>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>>> 
>>> -------- Original Message --------
>>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>>> Date: 2022-03-09 01:35
>>>  From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
>>> To: "Martin K. Petersen" <martin.petersen@oracle.com>
>>> 
>>> On Wed, Mar 9, 2022 at 9:26 AM Martin K. Petersen
>>> <martin.petersen@oracle.com> wrote:
>>>> 
>>>> 
>>>> Sreekanth,
>>>> 
>>>>> This series fix (remove) all sparse warnings generated when
>>>>> compiling
>>>>> the mpt3sas driver. All warnings are related to __iomem access and
>>>>> endianness.
>>>> 
>>>> Please review this series and validate the patch 5 modification.
>>> 
>>> Martin,
>>> This patch set looks good, but before acknowledging this patch set I
>>> just wanted to do some basic testing on a big endian machine.
>>> Currently I don't have a big endian machine, internally I am checking
>>> to get access to big endian machines. Meanwhile if anyone does a 
>>> basic
>>> testing on any big endian machine then please let me know. I will add
>>> the acknowledgement signature.
>>> 
>>> Thanks,
>>> Sreekanth
>>> 
>>>> 
>>>> Thanks!
>>>> 
>>>> --
>>>> Martin K. Petersen      Oracle Linux Engineering
>> 
> 

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Damien Le Moal]

On 2022/09/15 16:55, matoro wrote:
> Hi Damien, apologies for continuing to bother.  Did you get a chance to 
> put together a quick fix for this to test?

Not yet. Have been super busy with Plumbers & travel and other stuff. This is
still at the top of my to do list. Will try to send you something to test today.

> 
> -------- Original Message --------
> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
> Date: 2022-08-22 13:53
>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
> To: matoro <matoro_mailinglist_kernel@matoro.tk>
> 
> On 2022/08/22 10:51, matoro wrote:
>> Hi Damien, were you able to put together a fix to test?  We're up to
>> 5.19.3 now and 5.18 was just marked EOL, so I want to make sure this
>> doesn't drop off the radar.
> 
> No, sorry, I have been busy as I am traveling. Flying back home this 
> week, so
> likely will have more time next week.
> 
>>
>> -------- Original Message --------
>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>> Date: 2022-08-11 15:17
>>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
>> To: matoro <matoro_mailinglist_kernel@matoro.tk>
>>
>> On 2022/08/11 12:05, matoro wrote:
>>> Just a small update, the module stuff turned out to be a separate,
>>> unrelated regression.  I bisected that one also (applying these 
>>> reverts
>>> each time to allow me to boot) and reported it to Masahiro, who put in
>>> a
>>> fix for it here:
>>> https://lore.kernel.org/all/20220809141117.641543-1-masahiroy@kernel.org/
>>> .  So you can ignore that stuff.  Are these two commits still planned
>>> to
>>> be reverted?
>>
>> Revert should be a last resort (I really want to get rid of all these
>> sparse
>> warnings !). Let me first try to generate a fix for you to test.
>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>>> Date: 2022-08-02 19:36
>>>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
>>> To: matoro <matoro_mailinglist_kernel@matoro.tk>, Sreekanth Reddy
>>> <sreekanth.reddy@broadcom.com>
>>>
>>> On 8/3/22 05:27, matoro wrote:
>>>> Hi folks, sorry for the lateness, unfortunately this is in fact 
>>>> broken
>>>> on BE.  I use mpt3sas on sparc and my drives fail to come up on 5.19,
>>>> bisected to this patchset.  Reverting both of the endian-related
>>>> commits, b4efbec4c2a75b619fae4e8768be379e88c78687 and
>>>> 7ab4d2441b952977556672c2fe3f4c2a698cbb37, allows it to boot.  
>>>> However,
>>>> after booting, I can't load any modules - everything errors with
>>>> "disagrees about version of symbol module_layout".  I have completely
>>>> wiped out kernel sources, the module tree, and the kernel image,
>>>> rebuilding both from scratch with ONLY the revert patch applied, but 
>>>> I
>>>> still can't load any modules.  Presumably it would work with
>>>> CONFIG_MODVERSIONS=n, but these CRC checks are there for a reason and
>>>> I
>>>> can't tell if it has something to do with the revert or not.
>>>
>>> For b4efbec4c2a75b619fae4e8768be379e88c78687, removing the
>>> cpu_to_le32()
>>> call results in the bytes actually being reversed by writel()/readl()
>>> for
>>> your BE machine. So it looks like the values that need to be written 
>>> to
>>> the HBA have to be in CPU endian, not le32. Should be easy to fix.
>>> And for 7ab4d2441b952977556672c2fe3f4c2a698cbb37, this looks like the
>>> same
>>> problem.
>>>
>>> I will be traveling and busy this week, but I can have a look at a fix
>>> next Monday. If the Broadcom folks can send a fix faster than that,
>>> that
>>> is of course welcome :)
>>>
>>>>
>>>> $ modprobe --dump-modversions
>>>> /lib/modules/5.19.0-gentoo-sparc64/kernel/fs/openpromfs/openpromfs.ko
>>>> |
>>>> grep "module_layout"
>>>> 0xa6c23707      module_layout
>>>> $ grep "module_layout" /usr/src/linux/Module.symvers
>>>> 0xa6c23707      module_layout   vmlinux EXPORT_SYMBOL
>>>>
>>>> If you need real hardware access and do not have any on hand, please
>>>> reach out and I can provide temporary access!
>>>>
>>>> Here is the full error on vanilla 5.19:
>>>>
>>>> mpt3sas version 42.100.00.00 loaded
>>>> mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>>>> (32650280 kB)
>>>> mpt2sas_cm0: _base_wait_for_doorbell_not_used: failed due to timeout
>>>> count(5000), doorbell_reg(18000000)!
>>>> mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size
>>>> to
>>>> 4k
>>>> mpt2sas_cm0: MSI-X vectors supported: 1
>>>>           no of cores: 64, max_msix_vectors: -1
>>>> mpt2sas_cm0:  0 1 1
>>>> mpt2sas_cm0: pci_alloc_irq_vectors failed (r=-22) !!!
>>>> mpt2sas_cm0: High IOPs queues : disabled
>>>> mpt2sas0: IO-APIC enabled: IRQ 4
>>>> mpt2sas_cm0: iomem(0x0000084100000000), mapped(0x(____ptrval____)),
>>>> size(16384)
>>>> mpt2sas_cm0: ioport(0x0000085100000000), size(256)
>>>> mpt2sas_cm0: doorbell is in use (line=6869)
>>>> mpt2sas_cm0: _base_get_ioc_facts: handshake failed (r=-14)
>>>> mpt2sas_cm0: failure at
>>>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>>>> mpt2sas_cm1: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>>>> (32650280 kB)
>>>> mpt2sas_cm1: _base_wait_for_doorbell_not_used: failed due to timeout
>>>> count(5000), doorbell_reg(18000000)!
>>>> mpt2sas_cm1: CurrentHostPageSize is 0: Setting default host page size
>>>> to
>>>> 4k
>>>> mpt2sas_cm1: MSI-X vectors supported: 1
>>>>           no of cores: 64, max_msix_vectors: -1
>>>> mpt2sas_cm1:  0 1 1
>>>> mpt2sas_cm1: pci_alloc_irq_vectors failed (r=-22) !!!
>>>> mpt2sas_cm1: High IOPs queues : disabled
>>>> mpt2sas1: IO-APIC enabled: IRQ 5
>>>> mpt2sas_cm1: iomem(0x0000084120000000), mapped(0x(____ptrval____)),
>>>> size(16384)
>>>> mpt2sas_cm1: ioport(0x0000085100002000), size(256)
>>>> mpt2sas_cm1: doorbell is in use (line=6869)
>>>> mpt2sas_cm1: _base_get_ioc_facts: handshake failed (r=-14)
>>>> mpt2sas_cm1: failure at
>>>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>>>>
>>>> -------- Original Message --------
>>>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>>>> Date: 2022-03-09 01:35
>>>>  From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
>>>> To: "Martin K. Petersen" <martin.petersen@oracle.com>
>>>>
>>>> On Wed, Mar 9, 2022 at 9:26 AM Martin K. Petersen
>>>> <martin.petersen@oracle.com> wrote:
>>>>>
>>>>>
>>>>> Sreekanth,
>>>>>
>>>>>> This series fix (remove) all sparse warnings generated when
>>>>>> compiling
>>>>>> the mpt3sas driver. All warnings are related to __iomem access and
>>>>>> endianness.
>>>>>
>>>>> Please review this series and validate the patch 5 modification.
>>>>
>>>> Martin,
>>>> This patch set looks good, but before acknowledging this patch set I
>>>> just wanted to do some basic testing on a big endian machine.
>>>> Currently I don't have a big endian machine, internally I am checking
>>>> to get access to big endian machines. Meanwhile if anyone does a 
>>>> basic
>>>> testing on any big endian machine then please let me know. I will add
>>>> the acknowledgement signature.
>>>>
>>>> Thanks,
>>>> Sreekanth
>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> Martin K. Petersen      Oracle Linux Engineering
>>>
>>
> 

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings

[Damien Le Moal]

On 2022/09/15 16:55, matoro wrote:
> Hi Damien, apologies for continuing to bother.  Did you get a chance to 
> put together a quick fix for this to test?

I posted a revert for the 2 patches. I did try to fix this without reintroducing
the sparse warnings, but I do not have any specification for the Broadcom HBA
controller to know the exact endianness of the controller registers. So for now,
instead of blindly trying fixing this, I reverted.

> 
> -------- Original Message --------
> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
> Date: 2022-08-22 13:53
>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
> To: matoro <matoro_mailinglist_kernel@matoro.tk>
> 
> On 2022/08/22 10:51, matoro wrote:
>> Hi Damien, were you able to put together a fix to test?  We're up to
>> 5.19.3 now and 5.18 was just marked EOL, so I want to make sure this
>> doesn't drop off the radar.
> 
> No, sorry, I have been busy as I am traveling. Flying back home this 
> week, so
> likely will have more time next week.
> 
>>
>> -------- Original Message --------
>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>> Date: 2022-08-11 15:17
>>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
>> To: matoro <matoro_mailinglist_kernel@matoro.tk>
>>
>> On 2022/08/11 12:05, matoro wrote:
>>> Just a small update, the module stuff turned out to be a separate,
>>> unrelated regression.  I bisected that one also (applying these 
>>> reverts
>>> each time to allow me to boot) and reported it to Masahiro, who put in
>>> a
>>> fix for it here:
>>> https://lore.kernel.org/all/20220809141117.641543-1-masahiroy@kernel.org/
>>> .  So you can ignore that stuff.  Are these two commits still planned
>>> to
>>> be reverted?
>>
>> Revert should be a last resort (I really want to get rid of all these
>> sparse
>> warnings !). Let me first try to generate a fix for you to test.
>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>>> Date: 2022-08-02 19:36
>>>  From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
>>> To: matoro <matoro_mailinglist_kernel@matoro.tk>, Sreekanth Reddy
>>> <sreekanth.reddy@broadcom.com>
>>>
>>> On 8/3/22 05:27, matoro wrote:
>>>> Hi folks, sorry for the lateness, unfortunately this is in fact 
>>>> broken
>>>> on BE.  I use mpt3sas on sparc and my drives fail to come up on 5.19,
>>>> bisected to this patchset.  Reverting both of the endian-related
>>>> commits, b4efbec4c2a75b619fae4e8768be379e88c78687 and
>>>> 7ab4d2441b952977556672c2fe3f4c2a698cbb37, allows it to boot.  
>>>> However,
>>>> after booting, I can't load any modules - everything errors with
>>>> "disagrees about version of symbol module_layout".  I have completely
>>>> wiped out kernel sources, the module tree, and the kernel image,
>>>> rebuilding both from scratch with ONLY the revert patch applied, but 
>>>> I
>>>> still can't load any modules.  Presumably it would work with
>>>> CONFIG_MODVERSIONS=n, but these CRC checks are there for a reason and
>>>> I
>>>> can't tell if it has something to do with the revert or not.
>>>
>>> For b4efbec4c2a75b619fae4e8768be379e88c78687, removing the
>>> cpu_to_le32()
>>> call results in the bytes actually being reversed by writel()/readl()
>>> for
>>> your BE machine. So it looks like the values that need to be written 
>>> to
>>> the HBA have to be in CPU endian, not le32. Should be easy to fix.
>>> And for 7ab4d2441b952977556672c2fe3f4c2a698cbb37, this looks like the
>>> same
>>> problem.
>>>
>>> I will be traveling and busy this week, but I can have a look at a fix
>>> next Monday. If the Broadcom folks can send a fix faster than that,
>>> that
>>> is of course welcome :)
>>>
>>>>
>>>> $ modprobe --dump-modversions
>>>> /lib/modules/5.19.0-gentoo-sparc64/kernel/fs/openpromfs/openpromfs.ko
>>>> |
>>>> grep "module_layout"
>>>> 0xa6c23707      module_layout
>>>> $ grep "module_layout" /usr/src/linux/Module.symvers
>>>> 0xa6c23707      module_layout   vmlinux EXPORT_SYMBOL
>>>>
>>>> If you need real hardware access and do not have any on hand, please
>>>> reach out and I can provide temporary access!
>>>>
>>>> Here is the full error on vanilla 5.19:
>>>>
>>>> mpt3sas version 42.100.00.00 loaded
>>>> mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>>>> (32650280 kB)
>>>> mpt2sas_cm0: _base_wait_for_doorbell_not_used: failed due to timeout
>>>> count(5000), doorbell_reg(18000000)!
>>>> mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size
>>>> to
>>>> 4k
>>>> mpt2sas_cm0: MSI-X vectors supported: 1
>>>>           no of cores: 64, max_msix_vectors: -1
>>>> mpt2sas_cm0:  0 1 1
>>>> mpt2sas_cm0: pci_alloc_irq_vectors failed (r=-22) !!!
>>>> mpt2sas_cm0: High IOPs queues : disabled
>>>> mpt2sas0: IO-APIC enabled: IRQ 4
>>>> mpt2sas_cm0: iomem(0x0000084100000000), mapped(0x(____ptrval____)),
>>>> size(16384)
>>>> mpt2sas_cm0: ioport(0x0000085100000000), size(256)
>>>> mpt2sas_cm0: doorbell is in use (line=6869)
>>>> mpt2sas_cm0: _base_get_ioc_facts: handshake failed (r=-14)
>>>> mpt2sas_cm0: failure at
>>>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>>>> mpt2sas_cm1: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem
>>>> (32650280 kB)
>>>> mpt2sas_cm1: _base_wait_for_doorbell_not_used: failed due to timeout
>>>> count(5000), doorbell_reg(18000000)!
>>>> mpt2sas_cm1: CurrentHostPageSize is 0: Setting default host page size
>>>> to
>>>> 4k
>>>> mpt2sas_cm1: MSI-X vectors supported: 1
>>>>           no of cores: 64, max_msix_vectors: -1
>>>> mpt2sas_cm1:  0 1 1
>>>> mpt2sas_cm1: pci_alloc_irq_vectors failed (r=-22) !!!
>>>> mpt2sas_cm1: High IOPs queues : disabled
>>>> mpt2sas1: IO-APIC enabled: IRQ 5
>>>> mpt2sas_cm1: iomem(0x0000084120000000), mapped(0x(____ptrval____)),
>>>> size(16384)
>>>> mpt2sas_cm1: ioport(0x0000085100002000), size(256)
>>>> mpt2sas_cm1: doorbell is in use (line=6869)
>>>> mpt2sas_cm1: _base_get_ioc_facts: handshake failed (r=-14)
>>>> mpt2sas_cm1: failure at
>>>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:12336/_scsih_probe()!
>>>>
>>>> -------- Original Message --------
>>>> Subject: Re: [PATCH v3 0/5] Fix mpt3sas driver sparse warnings
>>>> Date: 2022-03-09 01:35
>>>>  From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
>>>> To: "Martin K. Petersen" <martin.petersen@oracle.com>
>>>>
>>>> On Wed, Mar 9, 2022 at 9:26 AM Martin K. Petersen
>>>> <martin.petersen@oracle.com> wrote:
>>>>>
>>>>>
>>>>> Sreekanth,
>>>>>
>>>>>> This series fix (remove) all sparse warnings generated when
>>>>>> compiling
>>>>>> the mpt3sas driver. All warnings are related to __iomem access and
>>>>>> endianness.
>>>>>
>>>>> Please review this series and validate the patch 5 modification.
>>>>
>>>> Martin,
>>>> This patch set looks good, but before acknowledging this patch set I
>>>> just wanted to do some basic testing on a big endian machine.
>>>> Currently I don't have a big endian machine, internally I am checking
>>>> to get access to big endian machines. Meanwhile if anyone does a 
>>>> basic
>>>> testing on any big endian machine then please let me know. I will add
>>>> the acknowledgement signature.
>>>>
>>>> Thanks,
>>>> Sreekanth
>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> Martin K. Petersen      Oracle Linux Engineering
>>>
>>
> 

-- 
Damien Le Moal
Western Digital Research