Re: [bisected] 5.12-rc1 hpsa regression: "scsi: hpsa: Correct dev cmds outstanding for retried cmds" breaks hpsa P600

[Tomas Henzl]

On 3/4/21 6:00 PM, don.br...@microchip.com wrote:
> -Original Message-
> From: Sergei Trofimovich [mailto:sly...@gmail.com] 
> Sent: Wednesday, March 3, 2021 4:04 PM
> To: Don Brace - C33706 
> Cc: glaub...@physik.fu-berlin.de; storagedev ; 
> linux-s...@vger.kernel.org; linux-i...@vger.kernel.org; 
> linux-kernel@vger.kernel.org; jszcz...@redhat.com; Scott Benesh - C33703 
> ; Scott Teel - C33730 ; 
> the...@redhat.com; martin.peter...@oracle.com
> Subject: Re: [bisected] 5.12-rc1 hpsa regression: "scsi: hpsa: Correct dev 
> cmds outstanding for retried cmds" breaks hpsa P600
> 
> Glad to hear the patch works. 
> The P600 is an unsupported controller that was removed some time ago (by us) 
> and re-added in this patch:
> commit 135ae6edeb51979d0998daf1357f149a7d6ebb08 scsi: hpsa: add support for 
> legacy boards
> Author: Hannes Reinecke 
> Date:   Tue Aug 15 08:58:04 2017 +0200
> 
> So, when testing the original patch, I no longer have a P600 to test with. It 
> used to be supported by our obsoleted cciss driver.

Do you know why this is specific to P600, since the struct is used only
internally in the driver and not used to communicate with the controller
or am I wrong?

> 
> Since patch f749d8b7a9896bc6e5ffe104cc64345037e0b152 scsi: hpsa: Correct dev 
> cmds outstanding for retried cmds has
> already been applied to Martin Petersons 5.13/scsi-queue, perhaps it would be 
> better to send up another patch to correct your alignment issue on these 
> legacy boards.
> 
> Wondering what others think about this?

I agree with you I'd prefer a new patch.

Thanks,
Tomas

> 
> Thanks,
> Don
> 

Re: [PATCH 10/10] mpt3sas: Bump mpt3sas driver version to v16.100.00.00

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Bump mpt3sas driver version to v16.100.00.00
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>
Tomas

Re: [PATCH 10/10] mpt3sas: Bump mpt3sas driver version to v16.100.00.00

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Bump mpt3sas driver version to v16.100.00.00
>
> Signed-off-by: Sreekanth Reddy 

Reviewed-by: Tomas Henzl 
Tomas

Re: [PATCH 09/10] mpt3sas: Adding support for SAS3616 HBA device

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Adding PNP ID of Mercator i.e. SAS3616 HBA device.
> Its device ID is 0xD1 and vendor ID is 0x1000.
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>
Tomas

Re: [PATCH 09/10] mpt3sas: Adding support for SAS3616 HBA device

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Adding PNP ID of Mercator i.e. SAS3616 HBA device.
> Its device ID is 0xD1 and vendor ID is 0x1000.
>
> Signed-off-by: Sreekanth Reddy 

Reviewed-by: Tomas Henzl 
Tomas

Re: [PATCH 04/10] mpt3sas: Fix removal and addition of vSES device during host reset

[Tomas Henzl]

On 10/11/2017 05:56 PM, James Bottomley wrote:
> On Wed, 2017-10-11 at 17:35 +0200, Tomas Henzl wrote:
>> On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
>>> For Dev Handles who value is less than hba's phys count number
>>>  driver will return HBA sas address value as a sas address.
>>> So for Virtual SES device also driver was returning HBA sas address
>>> instead
>>>  of Virtual SES sas address. So now updated the driver to return
>>>  Virtual SES's sas address for Virtual SES device instead of
>>>  HBA's sas address.
>>>
>>> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>
>> Signed-off-by: Tomas Henzl <the...@redhat.com>
> You mean Reviewed-by: I think?

Sure, sorry for that, corrected too late in 8/10
should I resend with  "Reviewed-by" ?

Tomas

>
> James
>

Re: [PATCH 04/10] mpt3sas: Fix removal and addition of vSES device during host reset

[Tomas Henzl]

On 10/11/2017 05:56 PM, James Bottomley wrote:
> On Wed, 2017-10-11 at 17:35 +0200, Tomas Henzl wrote:
>> On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
>>> For Dev Handles who value is less than hba's phys count number
>>>  driver will return HBA sas address value as a sas address.
>>> So for Virtual SES device also driver was returning HBA sas address
>>> instead
>>>  of Virtual SES sas address. So now updated the driver to return
>>>  Virtual SES's sas address for Virtual SES device instead of
>>>  HBA's sas address.
>>>
>>> Signed-off-by: Sreekanth Reddy 
>> Signed-off-by: Tomas Henzl 
> You mean Reviewed-by: I think?

Sure, sorry for that, corrected too late in 8/10
should I resend with  "Reviewed-by" ?

Tomas

>
> James
>

Re: [PATCH 08/10] mpt3sas: Fix possibility of using invalid Enclosure Handles for SAS device after host reset

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Enclosure handles are not updated after host reset.
> As a result, driver device structure is holding previously
>  assigned enclosure handle which is different from the
>  enclosure handle populated in the corresponding device page.
>
> Modified the driver to update devices enclosure handles after
>  host reset to current value, by referring the enclosure handles
>  from corresponding device pages
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Re: [PATCH 08/10] mpt3sas: Fix possibility of using invalid Enclosure Handles for SAS device after host reset

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Enclosure handles are not updated after host reset.
> As a result, driver device structure is holding previously
>  assigned enclosure handle which is different from the
>  enclosure handle populated in the corresponding device page.
>
> Modified the driver to update devices enclosure handles after
>  host reset to current value, by referring the enclosure handles
>  from corresponding device pages
>
> Signed-off-by: Sreekanth Reddy 

Reviewed-by: Tomas Henzl 

Re: [PATCH 08/10] mpt3sas: Fix possibility of using invalid Enclosure Handles for SAS device after host reset

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Enclosure handles are not updated after host reset.
> As a result, driver device structure is holding previously
>  assigned enclosure handle which is different from the
>  enclosure handle populated in the corresponding device page.
>
> Modified the driver to update devices enclosure handles after
>  host reset to current value, by referring the enclosure handles
>  from corresponding device pages
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>
> ---
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c | 117 
> ---
>  1 file changed, 81 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 17b934b..b819914 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -5383,6 +5383,52 @@ _scsih_check_access_status(struct MPT3SAS_ADAPTER 
> *ioc, u64 sas_address,
>  }
>  
>  /**
> + * _scsih_get_enclosure_logicalid_chassis_slot - get device's
> + *   EnclosureLogicalID and ChassisSlot information.
> + * @ioc: per adapter object
> + * @sas_device_pg0: SAS device page0
> + * @sas_device: per sas device object
> + *
> + * Returns nothing.
> + */
> +static void
> +_scsih_get_enclosure_logicalid_chassis_slot(struct MPT3SAS_ADAPTER *ioc,
> + Mpi2SasDevicePage0_t *sas_device_pg0, struct _sas_device *sas_device)
> +{
> + Mpi2ConfigReply_t mpi_reply;
> + Mpi2SasEnclosurePage0_t enclosure_pg0;
> +
> + if (!sas_device_pg0 || !sas_device)
> + return;

This test^ implies that  sas_device_pg0 or  sas_device can be null,
is that true?

Signed-off-by: Tomas Henzl <the...@redhat.com>

Re: [PATCH 08/10] mpt3sas: Fix possibility of using invalid Enclosure Handles for SAS device after host reset

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Enclosure handles are not updated after host reset.
> As a result, driver device structure is holding previously
>  assigned enclosure handle which is different from the
>  enclosure handle populated in the corresponding device page.
>
> Modified the driver to update devices enclosure handles after
>  host reset to current value, by referring the enclosure handles
>  from corresponding device pages
>
> Signed-off-by: Sreekanth Reddy 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c | 117 
> ---
>  1 file changed, 81 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 17b934b..b819914 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -5383,6 +5383,52 @@ _scsih_check_access_status(struct MPT3SAS_ADAPTER 
> *ioc, u64 sas_address,
>  }
>  
>  /**
> + * _scsih_get_enclosure_logicalid_chassis_slot - get device's
> + *   EnclosureLogicalID and ChassisSlot information.
> + * @ioc: per adapter object
> + * @sas_device_pg0: SAS device page0
> + * @sas_device: per sas device object
> + *
> + * Returns nothing.
> + */
> +static void
> +_scsih_get_enclosure_logicalid_chassis_slot(struct MPT3SAS_ADAPTER *ioc,
> + Mpi2SasDevicePage0_t *sas_device_pg0, struct _sas_device *sas_device)
> +{
> + Mpi2ConfigReply_t mpi_reply;
> + Mpi2SasEnclosurePage0_t enclosure_pg0;
> +
> + if (!sas_device_pg0 || !sas_device)
> + return;

This test^ implies that  sas_device_pg0 or  sas_device can be null,
is that true?

Signed-off-by: Tomas Henzl 

Re: [PATCH 07/10] mpt3sas: Display chassis slot information of the drive

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Display chassis slot information along with other drive location parameters
>  such as slot number and connector name in the logs; if chassis slot
>  validity bit is set in 'SAS Enclosure Page 0' while adding the drive.
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>

Signed-off-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH 07/10] mpt3sas: Display chassis slot information of the drive

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Display chassis slot information along with other drive location parameters
>  such as slot number and connector name in the logs; if chassis slot
>  validity bit is set in 'SAS Enclosure Page 0' while adding the drive.
>
> Signed-off-by: Sreekanth Reddy 

Signed-off-by: Tomas Henzl 

Tomas

Re: [PATCH 06/10] mpt3sas: Updated MPI headers to v2.00.48

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Updated MPI headers to v2.00.48
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>

Signed-off-by: Tomas Henzl <the...@redhat.com>
Tomas

Re: [PATCH 06/10] mpt3sas: Updated MPI headers to v2.00.48

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Updated MPI headers to v2.00.48
>
> Signed-off-by: Sreekanth Reddy 

Signed-off-by: Tomas Henzl 
Tomas

Re: [PATCH 05/10] mpt3sas: Fix IO error occurs on pulling out a drive from RAID1 volume created on two SATA drive

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Whenever IO for raid volume fails with IOCStatus
>  "MPI2_IOCSTATUS_SCSI_IOC_TERMINATED"and SCSIStatus equal to
>  "(MPI2_SCSI_STATE_TERMINATED | MPI2_SCSI_STATE_NO_SCSI_STATUS)"
>  then return the IO to SML with "DID_RESET"
>  (i.e. retry the IO infinite times) host bytes.
>
> Earlier driver is returning the IO with "DID_SOFT_ERROR"
>  that reties the IO quickly for five times but still
>  firmware needed some more time and hence IOs were failing.
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>

Signed-off-by: Tomas Henzl <the...@redhat.com>
Tomas

Re: [PATCH 05/10] mpt3sas: Fix IO error occurs on pulling out a drive from RAID1 volume created on two SATA drive

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Whenever IO for raid volume fails with IOCStatus
>  "MPI2_IOCSTATUS_SCSI_IOC_TERMINATED"and SCSIStatus equal to
>  "(MPI2_SCSI_STATE_TERMINATED | MPI2_SCSI_STATE_NO_SCSI_STATUS)"
>  then return the IO to SML with "DID_RESET"
>  (i.e. retry the IO infinite times) host bytes.
>
> Earlier driver is returning the IO with "DID_SOFT_ERROR"
>  that reties the IO quickly for five times but still
>  firmware needed some more time and hence IOs were failing.
>
> Signed-off-by: Sreekanth Reddy 

Signed-off-by: Tomas Henzl 
Tomas

Re: [PATCH 04/10] mpt3sas: Fix removal and addition of vSES device during host reset

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> For Dev Handles who value is less than hba's phys count number
>  driver will return HBA sas address value as a sas address.
> So for Virtual SES device also driver was returning HBA sas address instead
>  of Virtual SES sas address. So now updated the driver to return
>  Virtual SES's sas address for Virtual SES device instead of
>  HBA's sas address.
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>

Signed-off-by: Tomas Henzl <the...@redhat.com>

Re: [PATCH 04/10] mpt3sas: Fix removal and addition of vSES device during host reset

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> For Dev Handles who value is less than hba's phys count number
>  driver will return HBA sas address value as a sas address.
> So for Virtual SES device also driver was returning HBA sas address instead
>  of Virtual SES sas address. So now updated the driver to return
>  Virtual SES's sas address for Virtual SES device instead of
>  HBA's sas address.
>
> Signed-off-by: Sreekanth Reddy 

Signed-off-by: Tomas Henzl 

Re: [PATCH 03/10] mpt3sas: Reduce memory footprints in kdump kernel

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> To reduce the memory footprints of the driver in kdump kernel,
>  we have made below driver setting when system boots in to kdump kernel,
>
> 1. Used single MSI-x vector.
> 2. Disable RDPQ mode.
> 3. Set sg_table_size to 32 by default.
> 4) Set SCSI IO Queue depth to 200.
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>

I think that preferred is (though not much used yet) instead of 'reset_devices'
to use a 'is_kdump_kernel()' function. 

Signed-off-by: Tomas Henzl <the...@redhat.com>

Re: [PATCH 03/10] mpt3sas: Reduce memory footprints in kdump kernel

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> To reduce the memory footprints of the driver in kdump kernel,
>  we have made below driver setting when system boots in to kdump kernel,
>
> 1. Used single MSI-x vector.
> 2. Disable RDPQ mode.
> 3. Set sg_table_size to 32 by default.
> 4) Set SCSI IO Queue depth to 200.
>
> Signed-off-by: Sreekanth Reddy 

I think that preferred is (though not much used yet) instead of 'reset_devices'
to use a 'is_kdump_kernel()' function. 

Signed-off-by: Tomas Henzl 

Re: [PATCH 02/10] mpt3sas: Fixed memory leaks in driver

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Fixed below memory leak in driver,
>
> * While removing Expander devices - we are removing expander
>  device entry from the list before freeing it's child devices,
>  so while freeing child device we are finding its parent device
>  node as NULL and so we are not freeing the child device's
>  allocated data structures.
>  Updated the driver to remove the expander device from the list
>  only after freeing all its child devices.
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>

Signed-off-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH 02/10] mpt3sas: Fixed memory leaks in driver

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Fixed below memory leak in driver,
>
> * While removing Expander devices - we are removing expander
>  device entry from the list before freeing it's child devices,
>  so while freeing child device we are finding its parent device
>  node as NULL and so we are not freeing the child device's
>  allocated data structures.
>  Updated the driver to remove the expander device from the list
>  only after freeing all its child devices.
>
> Signed-off-by: Sreekanth Reddy 

Signed-off-by: Tomas Henzl 

Tomas

Re: [PATCH 01/10] mpt3sas: Processing of Cable Exception events

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Earlier Active Cable Exception event with reason code
> "Cable Degraded (0x02))" was added only for Active Cable,
> Now this event is extended to Passive cable too.
> So re-arranged display message accordingly.
>
> Also added Cable Exception Event even for SAS3008 & SAS3108 HBAs
> (i.e. MPI 2.5 spec supporting HBAs) earlier this event was
> enabled only for MPI 2.6 spec supporting HBA devices.
>
> Signed-off-by: Sreekanth Reddy <sreekanth.re...@broadcom.com>

Signed-off-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH 01/10] mpt3sas: Processing of Cable Exception events

[Tomas Henzl]

On 10/10/2017 03:11 PM, Sreekanth Reddy wrote:
> Earlier Active Cable Exception event with reason code
> "Cable Degraded (0x02))" was added only for Active Cable,
> Now this event is extended to Passive cable too.
> So re-arranged display message accordingly.
>
> Also added Cable Exception Event even for SAS3008 & SAS3108 HBAs
> (i.e. MPI 2.5 spec supporting HBAs) earlier this event was
> enabled only for MPI 2.6 spec supporting HBA devices.
>
> Signed-off-by: Sreekanth Reddy 

Signed-off-by: Tomas Henzl 

Tomas

Re: [PATCH V6 00/11] megaraid_sas: Updates for scsi-next

[Tomas Henzl]

On 23.12.2016 16:24, Tomas Henzl wrote:
> On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
>> Sasikumar Chandrasekaran (11):
>>   megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid
>> Controllers
>>   megaraid_sas: 128 MSIX Support
>>   megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid
>> Controllers
>>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and
>> IO Coalescing
>>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID
>> 1/10 Writes
>>   megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid
>> Controllers
>>   megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers
>> Capabilities
>>   megaraid_sas: Enable or Disable Fast path based on the PCI Threshold
>> Bandwidth
>>   megaraid_sas: ldio_outstanding variable is not decremented in
>> completion path
>>   megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid
>> Controllers
>>   megaraid_sas: driver version upgrade
>>
>>  drivers/scsi/megaraid/megaraid_sas.h| 139 --
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 240 +++--
>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 341 +++--
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 750 
>> +++-
>>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 364 --
>>  5 files changed, 1557 insertions(+), 277 deletions(-)
>>
> I finished review of this set and ack-ed it.
> There still is a large amount (~1600) of checkpatch errors,
> ERROR: DOS line endings
> ERROR: trailing whitespace
> ...
> I complained about this several times and was hoping that Sasi would fix all 
> that in V6
> but for some reason it hasn't been fixed.
> I don't want to stop the series only because of formatting issues,
> so well ok
> -tm

I looked into this once again and I think now, that the issue 
with the 'line endings' is an issue on my side. 
I'm sorry for that and please ignore my previous comment.
-tm

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 00/11] megaraid_sas: Updates for scsi-next

[Tomas Henzl]

On 23.12.2016 16:24, Tomas Henzl wrote:
> On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
>> Sasikumar Chandrasekaran (11):
>>   megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid
>> Controllers
>>   megaraid_sas: 128 MSIX Support
>>   megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid
>> Controllers
>>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and
>> IO Coalescing
>>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID
>> 1/10 Writes
>>   megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid
>> Controllers
>>   megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers
>> Capabilities
>>   megaraid_sas: Enable or Disable Fast path based on the PCI Threshold
>> Bandwidth
>>   megaraid_sas: ldio_outstanding variable is not decremented in
>> completion path
>>   megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid
>> Controllers
>>   megaraid_sas: driver version upgrade
>>
>>  drivers/scsi/megaraid/megaraid_sas.h| 139 --
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 240 +++--
>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 341 +++--
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 750 
>> +++-
>>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 364 --
>>  5 files changed, 1557 insertions(+), 277 deletions(-)
>>
> I finished review of this set and ack-ed it.
> There still is a large amount (~1600) of checkpatch errors,
> ERROR: DOS line endings
> ERROR: trailing whitespace
> ...
> I complained about this several times and was hoping that Sasi would fix all 
> that in V6
> but for some reason it hasn't been fixed.
> I don't want to stop the series only because of formatting issues,
> so well ok
> -tm

I looked into this once again and I think now, that the issue 
with the 'line endings' is an issue on my side. 
I'm sorry for that and please ignore my previous comment.
-tm

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 00/11] megaraid_sas: Updates for scsi-next

[Tomas Henzl]

On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
> Sasikumar Chandrasekaran (11):
>   megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: 128 MSIX Support
>   megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and
> IO Coalescing
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID
> 1/10 Writes
>   megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers
> Capabilities
>   megaraid_sas: Enable or Disable Fast path based on the PCI Threshold
> Bandwidth
>   megaraid_sas: ldio_outstanding variable is not decremented in
> completion path
>   megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: driver version upgrade
>
>  drivers/scsi/megaraid/megaraid_sas.h| 139 --
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 240 +++--
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 341 +++--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 750 
> +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 364 --
>  5 files changed, 1557 insertions(+), 277 deletions(-)
>
I finished review of this set and ack-ed it.
There still is a large amount (~1600) of checkpatch errors,
ERROR: DOS line endings
ERROR: trailing whitespace
...
I complained about this several times and was hoping that Sasi would fix all 
that in V6
but for some reason it hasn't been fixed.
I don't want to stop the series only because of formatting issues,
so well ok
-tm

Re: [PATCH V6 00/11] megaraid_sas: Updates for scsi-next

[Tomas Henzl]

On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
> Sasikumar Chandrasekaran (11):
>   megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: 128 MSIX Support
>   megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and
> IO Coalescing
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID
> 1/10 Writes
>   megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers
> Capabilities
>   megaraid_sas: Enable or Disable Fast path based on the PCI Threshold
> Bandwidth
>   megaraid_sas: ldio_outstanding variable is not decremented in
> completion path
>   megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: driver version upgrade
>
>  drivers/scsi/megaraid/megaraid_sas.h| 139 --
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 240 +++--
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 341 +++--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 750 
> +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 364 --
>  5 files changed, 1557 insertions(+), 277 deletions(-)
>
I finished review of this set and ack-ed it.
There still is a large amount (~1600) of checkpatch errors,
ERROR: DOS line endings
ERROR: trailing whitespace
...
I complained about this several times and was hoping that Sasi would fix all 
that in V6
but for some reason it hasn't been fixed.
I don't want to stop the series only because of formatting issues,
so well ok
-tm

Re: [PATCH V6 10/11] megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
> Update Linux driver to use new pdTargetId field for JBOD target ID
>
> This patch is depending on patch 9 and same as V5
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Re: [PATCH V6 10/11] megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
> Update Linux driver to use new pdTargetId field for JBOD target ID
>
> This patch is depending on patch 9 and same as V5
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Re: [PATCH V6 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
> Large SEQ IO workload should sent as non fast path commands
>
> This patch is depending on patch 7
>
> 80 chars per line limit is taken care around VD_EXT_DEBUG macro.
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Re: [PATCH V6 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
> Large SEQ IO workload should sent as non fast path commands
>
> This patch is depending on patch 7
>
> 80 chars per line limit is taken care around VD_EXT_DEBUG macro.
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Re: [PATCH V6 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap to 
> have different
> sizes for different number of supported VDs.
>
> This patch is depending on patch 5
>
> 80 chars per line limit is taken care around VD_EXT_DEBUG macro.
> NULL pointer check for desc_table has been removed.
> Few code indentation issues fixed.
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Re: [PATCH V6 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap to 
> have different
> sizes for different number of supported VDs.
>
> This patch is depending on patch 5
>
> 80 chars per line limit is taken care around VD_EXT_DEBUG macro.
> NULL pointer check for desc_table has been removed.
> Few code indentation issues fixed.
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Re: [PATCH V6 02/11] megaraid_sas: 128 MSIX Support

[Tomas Henzl]

On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid based Controllers will have the support for 128 MSI-X 
> vectors,
> resulting in the need to support 128 reply queues
>
> This patch is depending on patch 1 and same as V5
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Re: [PATCH V6 02/11] megaraid_sas: 128 MSIX Support

[Tomas Henzl]

On 23.12.2016 02:19, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid based Controllers will have the support for 128 MSI-X 
> vectors,
> resulting in the need to support 128 reply queues
>
> This patch is depending on patch 1 and same as V5
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 20.12.2016 02:51, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Thursday, December 15, 2016 10:10 AM
> To: Sasikumar PC; j...@kernel.org; h...@infradead.org
> Cc: linux-s...@vger.kernel.org; Sathya Prakash Veerichetty;
> linux-kernel@vger.kernel.org; Christopher Owens; Kiran Kumar Kasturi
> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path
> based on the PCI Threshold Bandwidth
>
> On 14.12.2016 22:54, Sasikumar PC wrote:
>> Hi Tomas,
>>
>> Please see my response inline
>>
>> Thanks
>> sasi
>>
>> -Original Message-
>> From: Tomas Henzl [mailto:the...@redhat.com]
>> Sent: Friday, December 09, 2016 8:59 AM
>> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
>> Cc: linux-s...@vger.kernel.org; sathya.prak...@broadcom.com;
>> linux-kernel@vger.kernel.org; christopher.ow...@broadcom.com;
>> kiran-kumar.kast...@broadcom.com
>> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast
>> path based on the PCI Threshold Bandwidth
>>
>> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>>> Large SEQ IO workload should sent as non fast path commands
>>>
>>> This patch is depending on patch 7
>>>
>>> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>
>>> ---
>>>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48
>> +
>>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>>>  5 files changed, 78 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>>> b/drivers/scsi/megaraid/megaraid_sas.h
>>> index 3e087ab..eb5be2b 100644
>>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>>  #define MFI_1068_FW_HANDSHAKE_OFFSET   0x64
>>>  #define MFI_1068_FW_READY  0x
>>>
>>> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
>>> +
>>>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>>> atomic_t ldio_outstanding;
>>> atomic_t fw_reset_no_pci_access;
>>>
>>> +   atomic64_t bytes_wrote; /* used for raid1 fast path enable or
>> disable */
>>> +   atomic_t r1_write_fp_capable;
>> Is a an atomic variable needed for a just boolean variable?
>> Sasi - As we need to synchronize timer thread and IO issue threads,
>> With atomic, at any point of time the value will be definitive.
>> With boolean, it depends, the value could be in transit while one
>> thread is reading and other is writing.
> This explanation is I think not good enough, as a write of a char value is
> atomic on all architectures. If you need synchronisation you probably need a
> spinlock.
> Tomash
>
> boolean may not be a char in all architectures/implementations. It could be
> implementation specific isn't it ?

On which arch? 

> Spin_Lock is heavier as the check is in IO path.

Lightest form of atomic variable for isolated write and read is probably a char 
- so why can't
you use that plain basic type to store a boolean value?

> We need it to be consistent
> non-transient value, not an exact synchronization.

Could you be please more specific - what exactly is the transient value other 
than true or false ?

> There could be more values that we may set this variable to, to make
> different decisions and value can be set in more places in future.
> Atomic will help it keep consistent and extensible.

And then you'll rename the variable and use bit operations or may use
different state values and for that a char or int which is atomic per se
are the best option.

You've tested the whole series so you try to not change anything in the series,
I'm trying to understand.
You wrote earlier here that an explicit synchronisation is not needed,
that means, that there is no race condition possible and the
code is just a bit less then ideal. ok, fine, i'll this pass.

>
> sasi
>
>>> +
>>> +
>>> struct megasas_instance_template *instancet;

Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 20.12.2016 02:51, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Thursday, December 15, 2016 10:10 AM
> To: Sasikumar PC; j...@kernel.org; h...@infradead.org
> Cc: linux-s...@vger.kernel.org; Sathya Prakash Veerichetty;
> linux-kernel@vger.kernel.org; Christopher Owens; Kiran Kumar Kasturi
> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path
> based on the PCI Threshold Bandwidth
>
> On 14.12.2016 22:54, Sasikumar PC wrote:
>> Hi Tomas,
>>
>> Please see my response inline
>>
>> Thanks
>> sasi
>>
>> -Original Message-
>> From: Tomas Henzl [mailto:the...@redhat.com]
>> Sent: Friday, December 09, 2016 8:59 AM
>> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
>> Cc: linux-s...@vger.kernel.org; sathya.prak...@broadcom.com;
>> linux-kernel@vger.kernel.org; christopher.ow...@broadcom.com;
>> kiran-kumar.kast...@broadcom.com
>> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast
>> path based on the PCI Threshold Bandwidth
>>
>> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>>> Large SEQ IO workload should sent as non fast path commands
>>>
>>> This patch is depending on patch 7
>>>
>>> Signed-off-by: Sasikumar Chandrasekaran 
>>> ---
>>>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48
>> +
>>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>>>  5 files changed, 78 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>>> b/drivers/scsi/megaraid/megaraid_sas.h
>>> index 3e087ab..eb5be2b 100644
>>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>>  #define MFI_1068_FW_HANDSHAKE_OFFSET   0x64
>>>  #define MFI_1068_FW_READY  0x
>>>
>>> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
>>> +
>>>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>>> atomic_t ldio_outstanding;
>>> atomic_t fw_reset_no_pci_access;
>>>
>>> +   atomic64_t bytes_wrote; /* used for raid1 fast path enable or
>> disable */
>>> +   atomic_t r1_write_fp_capable;
>> Is a an atomic variable needed for a just boolean variable?
>> Sasi - As we need to synchronize timer thread and IO issue threads,
>> With atomic, at any point of time the value will be definitive.
>> With boolean, it depends, the value could be in transit while one
>> thread is reading and other is writing.
> This explanation is I think not good enough, as a write of a char value is
> atomic on all architectures. If you need synchronisation you probably need a
> spinlock.
> Tomash
>
> boolean may not be a char in all architectures/implementations. It could be
> implementation specific isn't it ?

On which arch? 

> Spin_Lock is heavier as the check is in IO path.

Lightest form of atomic variable for isolated write and read is probably a char 
- so why can't
you use that plain basic type to store a boolean value?

> We need it to be consistent
> non-transient value, not an exact synchronization.

Could you be please more specific - what exactly is the transient value other 
than true or false ?

> There could be more values that we may set this variable to, to make
> different decisions and value can be set in more places in future.
> Atomic will help it keep consistent and extensible.

And then you'll rename the variable and use bit operations or may use
different state values and for that a char or int which is atomic per se
are the best option.

You've tested the whole series so you try to not change anything in the series,
I'm trying to understand.
You wrote earlier here that an explicit synchronisation is not needed,
that means, that there is no race condition possible and the
code is just a bit less then ideal. ok, fine, i'll this pass.

>
> sasi
>
>>> +
>>> +
>>> struct megasas_instance_template *instancet;
>>> struct taskl

Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 20.12.2016 02:51, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Sasikumar PC [mailto:sasikumar...@broadcom.com]
> Sent: Wednesday, December 14, 2016 4:49 PM
> To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org'
> Cc: 'linux-s...@vger.kernel.org'; Sathya Prakash Veerichetty;
> 'linux-kernel@vger.kernel.org'; Christopher Owens; Kiran Kumar Kasturi
> Subject: RE: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for
> SAS3.5 Generic Megaraid Controllers
>
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, December 09, 2016 7:55 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-s...@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-kernel@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for
> SAS3.5 Generic Megaraid Controllers
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap
> to have different
>> sizes for different number of supported VDs.
>>
>> This patch is depending on patch 5
>>
>> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|   7 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   |  61 --
>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 303
> 
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 223 
>>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 240
> ++
>>  5 files changed, 699 insertions(+), 135 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
> b/drivers/scsi/megaraid/megaraid_sas.h
>> index f4d6a94..3e087ab 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -1434,6 +1434,12 @@ enum FW_BOOT_CONTEXT {
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>  #define MR_MAX_MSIX_REG_ARRAY   16
>>  #define MR_RDPQ_MODE_OFFSET 0X0080
>> +
>> +#define MR_MAX_RAID_MAP_SIZE_OFFSET_SHIFT   16
>> +#define MR_MAX_RAID_MAP_SIZE_MASK   0x1FF
>> +#define MR_MIN_MAP_SIZE 0x1
>> +/* 64k */
>> +
>>  #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0X0100
>>
>>  /*
>> @@ -2152,6 +2158,7 @@ struct megasas_instance {
>>  bool fw_sync_cache_support;
>>  bool is_ventura;
>>  bool msix_combined;
>> +u16 max_raid_mapsize;
>>  };
>>  struct MR_LD_VF_MAP {
>>  u32 size;
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index c52f7be..3f06b57 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance
> *instance)
>>  static void megasas_update_ext_vd_details(struct megasas_instance
> *instance)
>>  {
>>  struct fusion_context *fusion;
>> -u32 old_map_sz;
>> -u32 new_map_sz;
>> +u32 ventura_map_sz = 0;
>>
>>  fusion = instance->ctrl_context;
>>  /* For MFI based controllers return dummy success */
>> @@ -4455,21 +4454,39 @@ static void megasas_update_ext_vd_details(struct
> megasas_instance *instance)
>>  instance->supportmax256vd ? "Extended VD(240 VD)firmware"
> :
>>  "Legacy(64 VD) firmware");
>>
>> -old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
>> -(sizeof(struct MR_LD_SPAN_MAP) *
>> -(instance->fw_supported_vd_count - 1));
>> -new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
>> -fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
>> -(sizeof(struct MR_LD_SPAN_MAP) *
>> -(instance->drv_supported_vd_count - 1));
>> -
>> -fusion->max_map_sz = max(old_map_sz, new_map_sz);
>> +if (instance->max_raid_mapsize) {
>> +ventura_map_sz = instance->max_raid_mapsize *
>> +MR_MIN_MAP_SIZE; /* 64k */
>> +fusion->current_map_sz = ventura_map_sz;
>> +fusion->m

Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 20.12.2016 02:51, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Sasikumar PC [mailto:sasikumar...@broadcom.com]
> Sent: Wednesday, December 14, 2016 4:49 PM
> To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org'
> Cc: 'linux-s...@vger.kernel.org'; Sathya Prakash Veerichetty;
> 'linux-kernel@vger.kernel.org'; Christopher Owens; Kiran Kumar Kasturi
> Subject: RE: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for
> SAS3.5 Generic Megaraid Controllers
>
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, December 09, 2016 7:55 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-s...@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-kernel@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for
> SAS3.5 Generic Megaraid Controllers
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap
> to have different
>> sizes for different number of supported VDs.
>>
>> This patch is depending on patch 5
>>
>> Signed-off-by: Sasikumar Chandrasekaran 
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|   7 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   |  61 --
>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 303
> 
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 223 
>>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 240
> ++
>>  5 files changed, 699 insertions(+), 135 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
> b/drivers/scsi/megaraid/megaraid_sas.h
>> index f4d6a94..3e087ab 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -1434,6 +1434,12 @@ enum FW_BOOT_CONTEXT {
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>  #define MR_MAX_MSIX_REG_ARRAY   16
>>  #define MR_RDPQ_MODE_OFFSET 0X0080
>> +
>> +#define MR_MAX_RAID_MAP_SIZE_OFFSET_SHIFT   16
>> +#define MR_MAX_RAID_MAP_SIZE_MASK   0x1FF
>> +#define MR_MIN_MAP_SIZE 0x1
>> +/* 64k */
>> +
>>  #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET 0X0100
>>
>>  /*
>> @@ -2152,6 +2158,7 @@ struct megasas_instance {
>>  bool fw_sync_cache_support;
>>  bool is_ventura;
>>  bool msix_combined;
>> +u16 max_raid_mapsize;
>>  };
>>  struct MR_LD_VF_MAP {
>>  u32 size;
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index c52f7be..3f06b57 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance
> *instance)
>>  static void megasas_update_ext_vd_details(struct megasas_instance
> *instance)
>>  {
>>  struct fusion_context *fusion;
>> -u32 old_map_sz;
>> -u32 new_map_sz;
>> +u32 ventura_map_sz = 0;
>>
>>  fusion = instance->ctrl_context;
>>  /* For MFI based controllers return dummy success */
>> @@ -4455,21 +4454,39 @@ static void megasas_update_ext_vd_details(struct
> megasas_instance *instance)
>>  instance->supportmax256vd ? "Extended VD(240 VD)firmware"
> :
>>  "Legacy(64 VD) firmware");
>>
>> -old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
>> -(sizeof(struct MR_LD_SPAN_MAP) *
>> -(instance->fw_supported_vd_count - 1));
>> -new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
>> -fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
>> -(sizeof(struct MR_LD_SPAN_MAP) *
>> -(instance->drv_supported_vd_count - 1));
>> -
>> -fusion->max_map_sz = max(old_map_sz, new_map_sz);
>> +if (instance->max_raid_mapsize) {
>> +ventura_map_sz = instance->max_raid_mapsize *
>> +MR_MIN_MAP_SIZE; /* 64k */
>> +fusion->current_map_sz = ventura_map_sz;
>> +fusion->max_map_sz = ventura_map_sz;
>>

Re: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support

[Tomas Henzl]

On 20.12.2016 02:50, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Sasikumar PC [mailto:sasikumar...@broadcom.com]
> Sent: Wednesday, December 14, 2016 4:43 PM
> To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org'
> Cc: 'linux-s...@vger.kernel.org'; Sathya Prakash Veerichetty;
> 'linux-kernel@vger.kernel.org'; Christopher Owens; Kiran Kumar Kasturi
> Subject: RE: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support
>
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Thursday, December 08, 2016 10:35 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-s...@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-kernel@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> SAS3.5 Generic Megaraid based Controllers will have the support for
>> 128 MSI-X vectors, resulting in the need to support 128 reply queues
>>
>> This patch is depending on patch 1
>>
>> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|  1 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 24
> +---
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c |  4 ++--
>>  3 files changed, 20 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> b/drivers/scsi/megaraid/megaraid_sas.h
>> index 72e16c2..9d4ca8d 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -2149,6 +2149,7 @@ struct megasas_instance {
>>  bool dev_handle;
>>  bool fw_sync_cache_support;
>>  bool is_ventura;
>> +bool msix_combined;
>>  };
>>  struct MR_LD_VF_MAP {
>>  u32 size;
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index efccf98..c583e0b 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -5086,13 +5086,7 @@ static int megasas_init_fw(struct
> megasas_instance *instance)
>>  goto fail_ready_state;
>>  }
>>
>> -/*
>> - * MSI-X host index 0 is common for all adapter.
>> - * It is used for all MPT based Adapters.
>> - */
>> -instance->reply_post_host_index_addr[0] =
>> -(u32 __iomem *)((u8 __iomem *)instance->reg_set +
>> -MPI2_REPLY_POST_HOST_INDEX_OFFSET);
>> +
>>
>>  /* Check if MSI-X is supported while in ready state */
>>  msix_enable = (instance->instancet->read_fw_status_reg(reg_set) &
> @@
>> -5110,6 +5104,9 @@ static int megasas_init_fw(struct megasas_instance
> *instance)
>>  instance->msix_vectors = ((scratch_pad_2
>>  & MR_MAX_REPLY_QUEUES_EXT_OFFSET)
>>  >>
> MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT) + 1;
>> +if (instance->msix_vectors > 16)
>> +instance->msix_combined = true;
>> +
>>  if (rdpq_enable)
>>  instance->is_rdpq = (scratch_pad_2
> & MR_RDPQ_MODE_OFFSET) ?
>>  1 : 0;
>> @@ -5143,6 +5140,19 @@ static int megasas_init_fw(struct
> megasas_instance *instance)
>>  else
>>  instance->msix_vectors = 0;
>>  }
> Have you tested this patch with the pci=nomsi kernel option?
> Sasi - Driver is tested with pci=nomsi option and looking good
>
> is it safe when msix_combined is true and pci_enable_msix_range fails so
> instance->msix_vectors is zero?
>
> msix_combined mode is dependent on how many vectors adapter supports, not
> the actual vectors used.
> It is correct to be in combined mode even if actual number of msix_vectors
> used are fewer than 16, if hardware is in combined mode

Ok,  thanks for explanation.

>
> Sasi
>
>
> tomash
>
>> +/*
>> + * MSI-X host index 0 is common for all adapter.
>> + * It is used for all MPT based Adapters.
>> + */
>> +if (instance->msix_combined) 

Re: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support

[Tomas Henzl]

On 20.12.2016 02:50, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Sasikumar PC [mailto:sasikumar...@broadcom.com]
> Sent: Wednesday, December 14, 2016 4:43 PM
> To: 'Tomas Henzl'; 'j...@kernel.org'; 'h...@infradead.org'
> Cc: 'linux-s...@vger.kernel.org'; Sathya Prakash Veerichetty;
> 'linux-kernel@vger.kernel.org'; Christopher Owens; Kiran Kumar Kasturi
> Subject: RE: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support
>
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Thursday, December 08, 2016 10:35 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-s...@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-kernel@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> SAS3.5 Generic Megaraid based Controllers will have the support for
>> 128 MSI-X vectors, resulting in the need to support 128 reply queues
>>
>> This patch is depending on patch 1
>>
>> Signed-off-by: Sasikumar Chandrasekaran 
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|  1 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 24
> +---
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c |  4 ++--
>>  3 files changed, 20 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> b/drivers/scsi/megaraid/megaraid_sas.h
>> index 72e16c2..9d4ca8d 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -2149,6 +2149,7 @@ struct megasas_instance {
>>  bool dev_handle;
>>  bool fw_sync_cache_support;
>>  bool is_ventura;
>> +bool msix_combined;
>>  };
>>  struct MR_LD_VF_MAP {
>>  u32 size;
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index efccf98..c583e0b 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -5086,13 +5086,7 @@ static int megasas_init_fw(struct
> megasas_instance *instance)
>>  goto fail_ready_state;
>>  }
>>
>> -/*
>> - * MSI-X host index 0 is common for all adapter.
>> - * It is used for all MPT based Adapters.
>> - */
>> -instance->reply_post_host_index_addr[0] =
>> -(u32 __iomem *)((u8 __iomem *)instance->reg_set +
>> -MPI2_REPLY_POST_HOST_INDEX_OFFSET);
>> +
>>
>>  /* Check if MSI-X is supported while in ready state */
>>  msix_enable = (instance->instancet->read_fw_status_reg(reg_set) &
> @@
>> -5110,6 +5104,9 @@ static int megasas_init_fw(struct megasas_instance
> *instance)
>>  instance->msix_vectors = ((scratch_pad_2
>>  & MR_MAX_REPLY_QUEUES_EXT_OFFSET)
>>  >>
> MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT) + 1;
>> +if (instance->msix_vectors > 16)
>> +instance->msix_combined = true;
>> +
>>  if (rdpq_enable)
>>  instance->is_rdpq = (scratch_pad_2
> & MR_RDPQ_MODE_OFFSET) ?
>>  1 : 0;
>> @@ -5143,6 +5140,19 @@ static int megasas_init_fw(struct
> megasas_instance *instance)
>>  else
>>  instance->msix_vectors = 0;
>>  }
> Have you tested this patch with the pci=nomsi kernel option?
> Sasi - Driver is tested with pci=nomsi option and looking good
>
> is it safe when msix_combined is true and pci_enable_msix_range fails so
> instance->msix_vectors is zero?
>
> msix_combined mode is dependent on how many vectors adapter supports, not
> the actual vectors used.
> It is correct to be in combined mode even if actual number of msix_vectors
> used are fewer than 16, if hardware is in combined mode

Ok,  thanks for explanation.

>
> Sasi
>
>
> tomash
>
>> +/*
>> + * MSI-X host index 0 is common for all adapter.
>> + * It is used for all MPT based Adapters.
>> + */
>> +if (instance->msix_combined) {
>> +instance-

Re: [PATCH V5 00/11] megaraid_sas: Updates for scsi-next

[Tomas Henzl]

On 14.12.2016 23:12, Sasikumar Chandrasekaran wrote:
> Sasikumar Chandrasekaran (11):
>   megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: 128 MSIX Support
>   megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and
> IO Coalescing
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID
> 1/10 Writes
>   megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers
> Capabilities
>   megaraid_sas: Enable or Disable Fast path based on the PCI Threshold
> Bandwidth
>   megaraid_sas: ldio_outstanding variable is not decremented in
> completion path
>   megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: driver version upgrade
>
>  drivers/scsi/megaraid/megaraid_sas.h| 139 --
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 233 +++--
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 293 +--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 742 
> +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 364 --
>  5 files changed, 1495 insertions(+), 276 deletions(-)
>
Sasi,
when I told you that you can in certain situations ignore the 80 chars per line 
limit
(and in specific cases it is even expected) it was not a free pass for you to
create the extremely long lines like you did.
Also when I complained in V1 about the 
ERROR: DOS line endings
#80: FILE: drivers/scsi/megaraid/megaraid_sas.h:59:
+#define PCI_DEVICE_ID_LSI_MECTOR^I^I0x00D4^M$
I was hoping you'd have removed these and didn't check any more - but they are 
still there
(Easy way how to avoid these errors is to use any linux editor, when you edit 
the patches.)
Some of those issues may be fixed when the patch is added to a git tree, so I'll
leave final decision on our maintainer and try to not comment any more on this 
kind of issues.

Cheers,
Tomas

Re: [PATCH V5 00/11] megaraid_sas: Updates for scsi-next

[Tomas Henzl]

On 14.12.2016 23:12, Sasikumar Chandrasekaran wrote:
> Sasikumar Chandrasekaran (11):
>   megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: 128 MSIX Support
>   megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and
> IO Coalescing
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID
> 1/10 Writes
>   megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers
> Capabilities
>   megaraid_sas: Enable or Disable Fast path based on the PCI Threshold
> Bandwidth
>   megaraid_sas: ldio_outstanding variable is not decremented in
> completion path
>   megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: driver version upgrade
>
>  drivers/scsi/megaraid/megaraid_sas.h| 139 --
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 233 +++--
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 293 +--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 742 
> +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 364 --
>  5 files changed, 1495 insertions(+), 276 deletions(-)
>
Sasi,
when I told you that you can in certain situations ignore the 80 chars per line 
limit
(and in specific cases it is even expected) it was not a free pass for you to
create the extremely long lines like you did.
Also when I complained in V1 about the 
ERROR: DOS line endings
#80: FILE: drivers/scsi/megaraid/megaraid_sas.h:59:
+#define PCI_DEVICE_ID_LSI_MECTOR^I^I0x00D4^M$
I was hoping you'd have removed these and didn't check any more - but they are 
still there
(Easy way how to avoid these errors is to use any linux editor, when you edit 
the patches.)
Some of those issues may be fixed when the patch is added to a git tree, so I'll
leave final decision on our maintainer and try to not comment any more on this 
kind of issues.

Cheers,
Tomas

Re: [PATCH V5 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 14.12.2016 23:13, Sasikumar Chandrasekaran wrote:
> Large SEQ IO workload should sent as non fast path commands
>
> This patch is depending on patch 7
> This patch is same as V4 and there is no specific update for V5

That means, that you have ignored my question regarding 'bytes_wrote'
I asked in V4. 
So could you please explain for what the mechanism in his asynchronous form 
is good?
Tomas


>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48 
> +
>  drivers/scsi/megaraid/megaraid_sas_fp.c |  6 
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>  5 files changed, 75 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 6ddf994..0696903 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>  #define MFI_1068_FW_HANDSHAKE_OFFSET 0x64
>  #define MFI_1068_FW_READY0x
>  
> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
> +
>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>   atomic_t ldio_outstanding;
>   atomic_t fw_reset_no_pci_access;
>  
> + atomic64_t bytes_wrote; /* used for raid1 fast path enable or disable */
> + atomic_t r1_write_fp_capable;
> +
> +
>   struct megasas_instance_template *instancet;
>   struct tasklet_struct isr_tasklet;
>   struct work_struct work_init;
> @@ -2142,6 +2148,7 @@ struct megasas_instance {
>   long reset_flags;
>   struct mutex reset_mutex;
>   struct timer_list sriov_heartbeat_timer;
> + struct timer_list r1_fp_hold_timer;
>   char skip_heartbeat_timer_del;
>   u8 requestorId;
>   char PlasmaFW111;
> @@ -2158,6 +2165,7 @@ struct megasas_instance {
>   bool is_ventura;
>   bool msix_combined;
>   u16 max_raid_mapsize;
> + u64 pci_threshold_bandwidth; /* used to control the fp writes */
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 4518ffc..15a894b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance 
> *instance)
>   }
>   /* Complete outstanding ioctls when adapter is killed */
>   megasas_complete_outstanding_ioctls(instance);
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>  }
>  
>   /**
> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned long 
> instance_addr)
>   }
>  }
>  
> +/*Handler for disabling/enabling raid 1 fast paths*/
> +void megasas_change_r1_fp_status(unsigned long instance_addr)
> +{
> + struct megasas_instance *instance =
> + (struct megasas_instance *)instance_addr;
> + if (atomic64_read(>bytes_wrote) >=
> + instance->pci_threshold_bandwidth) {
> +
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 0);
> + } else {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + }
> + mod_timer(>r1_fp_hold_timer,
> +  jiffies + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> +}
> +
>  /**
>   * megasas_wait_for_outstanding -Wait for all outstanding cmds
>   * @instance:Adapter soft state
> @@ -5357,6 +5378,17 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   instance->skip_heartbeat_timer_del = 1;
>   }
>  
> + if (instance->is_ventura) {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + megasas_start_timer(instance,
> + >r1_fp_hold_timer,
> + megasas_change_r1_fp_status,
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + dev_info(>pdev->dev, "starting the 
> raid 1 fp timer with interval %d\n",
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + }
> +
>   return 0;
>  
>  fail_get_ld_pd_list:
> @@ -6147,6 +6179,9 @@ static void megasas_shutdown_controller(struct 
> megasas_instance *instance,
>   if (instance->requestorId && !instance->skip_heartbeat_timer_del)
>   del_timer_sync(>sriov_heartbeat_timer);
>  
> + if (instance->is_ventura)
> + 

Re: [PATCH V5 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 14.12.2016 23:13, Sasikumar Chandrasekaran wrote:
> Large SEQ IO workload should sent as non fast path commands
>
> This patch is depending on patch 7
> This patch is same as V4 and there is no specific update for V5

That means, that you have ignored my question regarding 'bytes_wrote'
I asked in V4. 
So could you please explain for what the mechanism in his asynchronous form 
is good?
Tomas


>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48 
> +
>  drivers/scsi/megaraid/megaraid_sas_fp.c |  6 
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>  5 files changed, 75 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 6ddf994..0696903 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>  #define MFI_1068_FW_HANDSHAKE_OFFSET 0x64
>  #define MFI_1068_FW_READY0x
>  
> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
> +
>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>   atomic_t ldio_outstanding;
>   atomic_t fw_reset_no_pci_access;
>  
> + atomic64_t bytes_wrote; /* used for raid1 fast path enable or disable */
> + atomic_t r1_write_fp_capable;
> +
> +
>   struct megasas_instance_template *instancet;
>   struct tasklet_struct isr_tasklet;
>   struct work_struct work_init;
> @@ -2142,6 +2148,7 @@ struct megasas_instance {
>   long reset_flags;
>   struct mutex reset_mutex;
>   struct timer_list sriov_heartbeat_timer;
> + struct timer_list r1_fp_hold_timer;
>   char skip_heartbeat_timer_del;
>   u8 requestorId;
>   char PlasmaFW111;
> @@ -2158,6 +2165,7 @@ struct megasas_instance {
>   bool is_ventura;
>   bool msix_combined;
>   u16 max_raid_mapsize;
> + u64 pci_threshold_bandwidth; /* used to control the fp writes */
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 4518ffc..15a894b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance 
> *instance)
>   }
>   /* Complete outstanding ioctls when adapter is killed */
>   megasas_complete_outstanding_ioctls(instance);
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>  }
>  
>   /**
> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned long 
> instance_addr)
>   }
>  }
>  
> +/*Handler for disabling/enabling raid 1 fast paths*/
> +void megasas_change_r1_fp_status(unsigned long instance_addr)
> +{
> + struct megasas_instance *instance =
> + (struct megasas_instance *)instance_addr;
> + if (atomic64_read(>bytes_wrote) >=
> + instance->pci_threshold_bandwidth) {
> +
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 0);
> + } else {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + }
> + mod_timer(>r1_fp_hold_timer,
> +  jiffies + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> +}
> +
>  /**
>   * megasas_wait_for_outstanding -Wait for all outstanding cmds
>   * @instance:Adapter soft state
> @@ -5357,6 +5378,17 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   instance->skip_heartbeat_timer_del = 1;
>   }
>  
> + if (instance->is_ventura) {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + megasas_start_timer(instance,
> + >r1_fp_hold_timer,
> + megasas_change_r1_fp_status,
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + dev_info(>pdev->dev, "starting the 
> raid 1 fp timer with interval %d\n",
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + }
> +
>   return 0;
>  
>  fail_get_ld_pd_list:
> @@ -6147,6 +6179,9 @@ static void megasas_shutdown_controller(struct 
> megasas_instance *instance,
>   if (instance->requestorId && !instance->skip_heartbeat_timer_del)
>   del_timer_sync(>sriov_heartbeat_timer);
>  
> + if (instance->is_ventura)
> + 

Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 14.12.2016 22:54, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, December 09, 2016 8:59 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-s...@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-kernel@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path
> based on the PCI Threshold Bandwidth
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> Large SEQ IO workload should sent as non fast path commands
>>
>> This patch is depending on patch 7
>>
>> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48
> +
>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>>  5 files changed, 78 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> b/drivers/scsi/megaraid/megaraid_sas.h
>> index 3e087ab..eb5be2b 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>  #define MFI_1068_FW_HANDSHAKE_OFFSET0x64
>>  #define MFI_1068_FW_READY   0x
>>
>> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
>> +
>>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>>  atomic_t ldio_outstanding;
>>  atomic_t fw_reset_no_pci_access;
>>
>> +atomic64_t bytes_wrote; /* used for raid1 fast path enable or
> disable */
>> +atomic_t r1_write_fp_capable;
> Is a an atomic variable needed for a just boolean variable?
> Sasi - As we need to synchronize timer thread and IO issue threads,
> With atomic, at any point of time the value will be definitive.
> With boolean, it depends, the value could be in transit while
> one thread is reading and other is writing.

This explanation is I think not good enough, as a write of a char value
is atomic on all architectures. If you need synchronisation you probably
need a spinlock.
tomash

>
>> +
>> +
>>  struct megasas_instance_template *instancet;
>>  struct tasklet_struct isr_tasklet;
>>  struct work_struct work_init;
>> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>>  long reset_flags;
>>  struct mutex reset_mutex;
>>  struct timer_list sriov_heartbeat_timer;
>> +struct timer_list r1_fp_hold_timer;
>>  char skip_heartbeat_timer_del;
>>  u8 requestorId;
>>  char PlasmaFW111;
>> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>>  bool is_ventura;
>>  bool msix_combined;
>>  u16 max_raid_mapsize;
>> +u64 pci_threshold_bandwidth; /* used to control the fp writes */
>>  };
>>  struct MR_LD_VF_MAP {
>>  u32 size;
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index 8aafb59..899d25c 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance
> *instance)
>>  }
>>  /* Complete outstanding ioctls when adapter is killed */
>>  megasas_complete_outstanding_ioctls(instance);
>> +if (instance->is_ventura)
>> +del_timer_sync(>r1_fp_hold_timer);
>> +
>>  }
>>
>>   /**
>> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned
> long instance_addr)
>>  }
>>  }
>>
>> +/*Handler for disabling/enabling raid 1 fast paths*/ void
>> +megasas_change_r1_fp_status(unsigned long instance_addr) {
>> +struct megasas_instance *instance =
>> +(struct megasas_instance *)instance_addr;
>> +if (atomic64_read(>bytes_wrote) >=
>> +instance->pci_threshold_bandwidth)
> {
>> +
>> +atomic64_set(>bytes_wrote, 0);
>> +atomic_set(>r1_wr

Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 14.12.2016 22:54, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, December 09, 2016 8:59 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-s...@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-kernel@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path
> based on the PCI Threshold Bandwidth
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> Large SEQ IO workload should sent as non fast path commands
>>
>> This patch is depending on patch 7
>>
>> Signed-off-by: Sasikumar Chandrasekaran 
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48
> +
>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>>  5 files changed, 78 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> b/drivers/scsi/megaraid/megaraid_sas.h
>> index 3e087ab..eb5be2b 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>  #define MFI_1068_FW_HANDSHAKE_OFFSET0x64
>>  #define MFI_1068_FW_READY   0x
>>
>> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
>> +
>>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>>  atomic_t ldio_outstanding;
>>  atomic_t fw_reset_no_pci_access;
>>
>> +atomic64_t bytes_wrote; /* used for raid1 fast path enable or
> disable */
>> +atomic_t r1_write_fp_capable;
> Is a an atomic variable needed for a just boolean variable?
> Sasi - As we need to synchronize timer thread and IO issue threads,
> With atomic, at any point of time the value will be definitive.
> With boolean, it depends, the value could be in transit while
> one thread is reading and other is writing.

This explanation is I think not good enough, as a write of a char value
is atomic on all architectures. If you need synchronisation you probably
need a spinlock.
tomash

>
>> +
>> +
>>  struct megasas_instance_template *instancet;
>>  struct tasklet_struct isr_tasklet;
>>  struct work_struct work_init;
>> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>>  long reset_flags;
>>  struct mutex reset_mutex;
>>  struct timer_list sriov_heartbeat_timer;
>> +struct timer_list r1_fp_hold_timer;
>>  char skip_heartbeat_timer_del;
>>  u8 requestorId;
>>  char PlasmaFW111;
>> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>>  bool is_ventura;
>>  bool msix_combined;
>>  u16 max_raid_mapsize;
>> +u64 pci_threshold_bandwidth; /* used to control the fp writes */
>>  };
>>  struct MR_LD_VF_MAP {
>>  u32 size;
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index 8aafb59..899d25c 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance
> *instance)
>>  }
>>  /* Complete outstanding ioctls when adapter is killed */
>>  megasas_complete_outstanding_ioctls(instance);
>> +if (instance->is_ventura)
>> +del_timer_sync(>r1_fp_hold_timer);
>> +
>>  }
>>
>>   /**
>> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned
> long instance_addr)
>>  }
>>  }
>>
>> +/*Handler for disabling/enabling raid 1 fast paths*/ void
>> +megasas_change_r1_fp_status(unsigned long instance_addr) {
>> +struct megasas_instance *instance =
>> +(struct megasas_instance *)instance_addr;
>> +if (atomic64_read(>bytes_wrote) >=
>> +instance->pci_threshold_bandwidth)
> {
>> +
>> +atomic64_set(>bytes_wrote, 0);
>> +atomic_set(>r1_write_fp_capable, 0);
>> +} el

Re: [PATCH V5 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 14.12.2016 23:13, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap to 
> have different
> sizes for different number of supported VDs.
>
> This patch is depending on patch 5
> Code indentation is fixed for VD_EXT_DEBUG macro
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   7 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  53 --
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 254 
> +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 219 +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 240 ++
>  5 files changed, 636 insertions(+), 137 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index a96889c..6ddf994 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1434,6 +1434,12 @@ enum FW_BOOT_CONTEXT {
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>  #define MR_MAX_MSIX_REG_ARRAY   16
>  #define MR_RDPQ_MODE_OFFSET  0X0080
> +
> +#define MR_MAX_RAID_MAP_SIZE_OFFSET_SHIFT16
> +#define MR_MAX_RAID_MAP_SIZE_MASK0x1FF
> +#define MR_MIN_MAP_SIZE  0x1
> +/* 64k */
> +
>  #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET  0X0100
>  
>  /*
> @@ -2151,6 +2157,7 @@ struct megasas_instance {
>   bool fw_sync_cache_support;
>   bool is_ventura;
>   bool msix_combined;
> + u16 max_raid_mapsize;
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 8e20992..92cb02f 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance 
> *instance)
>  static void megasas_update_ext_vd_details(struct megasas_instance *instance)
>  {
>   struct fusion_context *fusion;
> - u32 old_map_sz;
> - u32 new_map_sz;
> + u32 ventura_map_sz = 0;
>  
>   fusion = instance->ctrl_context;
>   /* For MFI based controllers return dummy success */
> @@ -4455,21 +4454,34 @@ static void megasas_update_ext_vd_details(struct 
> megasas_instance *instance)
>   instance->supportmax256vd ? "Extended VD(240 VD)firmware" :
>   "Legacy(64 VD) firmware");
>  
> - old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->fw_supported_vd_count - 1));
> - new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
> - fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->drv_supported_vd_count - 1));
> + if (instance->max_raid_mapsize) {
> + ventura_map_sz = instance->max_raid_mapsize *
> + MR_MIN_MAP_SIZE; /* 64k */
> + fusion->current_map_sz = ventura_map_sz;
> + fusion->max_map_sz = ventura_map_sz;
> + } else {
> + fusion->old_map_sz =  sizeof(struct MR_FW_RAID_MAP) +
> + (sizeof(struct MR_LD_SPAN_MAP) *
> + (instance->fw_supported_vd_count - 1));
> + fusion->new_map_sz =  sizeof(struct MR_FW_RAID_MAP_EXT);
>  
> - fusion->max_map_sz = max(old_map_sz, new_map_sz);
> + fusion->max_map_sz =
> + max(fusion->old_map_sz, fusion->new_map_sz);
>  
> + if (instance->supportmax256vd)
> + fusion->current_map_sz = fusion->new_map_sz;
> + else
> + fusion->current_map_sz = fusion->old_map_sz;
> + }
> + /* irrespective of FW raid maps, driver raid map is constant */
> + fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP_ALL);
>  
> - if (instance->supportmax256vd)
> - fusion->current_map_sz = new_map_sz;
> - else
> - fusion->current_map_sz = old_map_sz;
> +#if VD_EXT_DEBUG
> + dev_info(>pdev->dev, "instance->max_raid_mapsize 0x%x\n ", 
> instance->max_raid_mapsize);
> + dev_info(>pdev->dev, "new_map_sz = 0x%x, old_map_sz = 
> 0x%x\n", fusion->new_map_sz, fusion->old_map_sz);
> + dev_info(>pdev->dev, "ventura_map_sz = 0x%x, current_map_sz = 
> 0x%x\n", ventura_map_sz, fusion->current_map_sz);
> + dev_info(>pdev->dev, "fusion->drv_map_sz =0x%x, size of 
> driver raid map 0x%lx\n", fusion->drv_map_sz, sizeof(struct 
> MR_DRV_RAID_MAP_ALL));
> +#endif
>  }
>  
>  /**
> @@ -4996,7 +5008,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  {
>   u32 max_sectors_1;
>   u32 max_sectors_2;
> - u32 tmp_sectors, 

Re: [PATCH V5 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 14.12.2016 23:13, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap to 
> have different
> sizes for different number of supported VDs.
>
> This patch is depending on patch 5
> Code indentation is fixed for VD_EXT_DEBUG macro
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   7 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  53 --
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 254 
> +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 219 +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 240 ++
>  5 files changed, 636 insertions(+), 137 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index a96889c..6ddf994 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1434,6 +1434,12 @@ enum FW_BOOT_CONTEXT {
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>  #define MR_MAX_MSIX_REG_ARRAY   16
>  #define MR_RDPQ_MODE_OFFSET  0X0080
> +
> +#define MR_MAX_RAID_MAP_SIZE_OFFSET_SHIFT16
> +#define MR_MAX_RAID_MAP_SIZE_MASK0x1FF
> +#define MR_MIN_MAP_SIZE  0x1
> +/* 64k */
> +
>  #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET  0X0100
>  
>  /*
> @@ -2151,6 +2157,7 @@ struct megasas_instance {
>   bool fw_sync_cache_support;
>   bool is_ventura;
>   bool msix_combined;
> + u16 max_raid_mapsize;
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 8e20992..92cb02f 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance 
> *instance)
>  static void megasas_update_ext_vd_details(struct megasas_instance *instance)
>  {
>   struct fusion_context *fusion;
> - u32 old_map_sz;
> - u32 new_map_sz;
> + u32 ventura_map_sz = 0;
>  
>   fusion = instance->ctrl_context;
>   /* For MFI based controllers return dummy success */
> @@ -4455,21 +4454,34 @@ static void megasas_update_ext_vd_details(struct 
> megasas_instance *instance)
>   instance->supportmax256vd ? "Extended VD(240 VD)firmware" :
>   "Legacy(64 VD) firmware");
>  
> - old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->fw_supported_vd_count - 1));
> - new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
> - fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->drv_supported_vd_count - 1));
> + if (instance->max_raid_mapsize) {
> + ventura_map_sz = instance->max_raid_mapsize *
> + MR_MIN_MAP_SIZE; /* 64k */
> + fusion->current_map_sz = ventura_map_sz;
> + fusion->max_map_sz = ventura_map_sz;
> + } else {
> + fusion->old_map_sz =  sizeof(struct MR_FW_RAID_MAP) +
> + (sizeof(struct MR_LD_SPAN_MAP) *
> + (instance->fw_supported_vd_count - 1));
> + fusion->new_map_sz =  sizeof(struct MR_FW_RAID_MAP_EXT);
>  
> - fusion->max_map_sz = max(old_map_sz, new_map_sz);
> + fusion->max_map_sz =
> + max(fusion->old_map_sz, fusion->new_map_sz);
>  
> + if (instance->supportmax256vd)
> + fusion->current_map_sz = fusion->new_map_sz;
> + else
> + fusion->current_map_sz = fusion->old_map_sz;
> + }
> + /* irrespective of FW raid maps, driver raid map is constant */
> + fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP_ALL);
>  
> - if (instance->supportmax256vd)
> - fusion->current_map_sz = new_map_sz;
> - else
> - fusion->current_map_sz = old_map_sz;
> +#if VD_EXT_DEBUG
> + dev_info(>pdev->dev, "instance->max_raid_mapsize 0x%x\n ", 
> instance->max_raid_mapsize);
> + dev_info(>pdev->dev, "new_map_sz = 0x%x, old_map_sz = 
> 0x%x\n", fusion->new_map_sz, fusion->old_map_sz);
> + dev_info(>pdev->dev, "ventura_map_sz = 0x%x, current_map_sz = 
> 0x%x\n", ventura_map_sz, fusion->current_map_sz);
> + dev_info(>pdev->dev, "fusion->drv_map_sz =0x%x, size of 
> driver raid map 0x%lx\n", fusion->drv_map_sz, sizeof(struct 
> MR_DRV_RAID_MAP_ALL));
> +#endif
>  }
>  
>  /**
> @@ -4996,7 +5008,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  {
>   u32 max_sectors_1;
>   u32 max_sectors_2;
> - u32 tmp_sectors, msix_enable, 

Re: [PATCH V5 04/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and IO Coalescing

[Tomas Henzl]

On 14.12.2016 23:13, Sasikumar Chandrasekaran wrote:
> Detect sequential IO streams and pass those IOs directly to FW.
>
> This patch is depending on patch 3
> This patch is same as V4 and there is no specific update for V5

That is not correct, I'm glad to see several whitespace changes
(for example a non-ascii char has been removed).
Other then the indentation is still not correct - see in text.
I haven't found any other important issues so ok.

>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>
> Reviewed-by: Tomas Henzl <the...@redhat.com>
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   1 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  43 +++-
>  drivers/scsi/megaraid/megaraid_sas_fp.c |   2 +
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 163 
> +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 117 +++-
>  5 files changed, 295 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 36aac88..3d86bc6 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -2070,6 +2070,7 @@ struct megasas_instance {
>   /* used to sync fire the cmd to fw */
>   spinlock_t hba_lock;
>   /* used to synch producer, consumer ptrs in dpc */
> + spinlock_t stream_lock;
>   spinlock_t completion_lock;
>   struct dma_pool *frame_dma_pool;
>   struct dma_pool *sense_dma_pool;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 5a1a53b..8e20992 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5001,7 +5001,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   struct megasas_register_set __iomem *reg_set;
>   struct megasas_ctrl_info *ctrl_info = NULL;
>   unsigned long bar_list;
> - int i, loop, fw_msix_count = 0;
> + int i, j, loop, fw_msix_count = 0;
>   struct IOV_111 *iovPtr;
>   struct fusion_context *fusion;
>  
> @@ -5194,6 +5194,36 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   }
>  
>   memset(instance->ld_ids, 0xff, MEGASAS_MAX_LD_IDS);
> +
> + /* stream detection initialization */
> + if (instance->is_ventura) {
> + fusion->stream_detect_by_ld =
> + kzalloc(sizeof(struct LD_STREAM_DETECT *)
> + * MAX_LOGICAL_DRIVES_EXT,
> + GFP_KERNEL);
> + if (!fusion->stream_detect_by_ld) {
> + dev_err(>pdev->dev,
> + "unable to allocate stream detection 
> for pool of LDs\n");
> + goto fail_get_ld_pd_list;
> + }
> + for (i = 0; i < MAX_LOGICAL_DRIVES_EXT; ++i) {
> + fusion->stream_detect_by_ld[i] =
> + kmalloc(sizeof(struct LD_STREAM_DETECT),
> + GFP_KERNEL);
> + if (!fusion->stream_detect_by_ld[i]) {
> + dev_err(>pdev->dev,
> + "unable to allocate stream detect by 
> LD\n ");
> +  for (j = 0; j < i; ++j)
> + kfree(fusion->stream_detect_by_ld[j]);
> + kfree(fusion->stream_detect_by_ld);
> + fusion->stream_detect_by_ld = NULL;
> + goto fail_get_ld_pd_list;
> + }
> + fusion->stream_detect_by_ld[i]->mru_bit_map
> + = MR_STREAM_BITMAP;
> + }
> + }
> +
>   if (megasas_ld_list_query(instance,
> MR_LD_QUERY_TYPE_EXPOSED_TO_HOST))
>   megasas_get_ld_list(instance);
> @@ -5313,6 +5343,8 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  
>   return 0;
>  
> +fail_get_ld_pd_list:
> + instance->instancet->disable_intr(instance);
>  fail_get_pd_list:
>   instance->instancet->disable_intr(instance);
>  fail_init_adapter:
> @@ -5846,6 +5878,7 @@ static int megasas_probe_one(struct pci_dev *pdev,
>  
>   spin_lock_init(>mfi_pool_lock);
>   spin_lock_init(>hba_lock);
> + spin_lock_init(>stream_lock);
>   spin_lock_init(>completion_lock);
>  
>   mutex_init(>reset_mutex);
> @@ -6353,6 +6386,14 @@ static void megasas_detach_one(struct pci_de

Re: [PATCH V5 04/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and IO Coalescing

[Tomas Henzl]

On 14.12.2016 23:13, Sasikumar Chandrasekaran wrote:
> Detect sequential IO streams and pass those IOs directly to FW.
>
> This patch is depending on patch 3
> This patch is same as V4 and there is no specific update for V5

That is not correct, I'm glad to see several whitespace changes
(for example a non-ascii char has been removed).
Other then the indentation is still not correct - see in text.
I haven't found any other important issues so ok.

>
> Signed-off-by: Sasikumar Chandrasekaran 
> Reviewed-by: Tomas Henzl 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   1 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  43 +++-
>  drivers/scsi/megaraid/megaraid_sas_fp.c |   2 +
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 163 
> +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 117 +++-
>  5 files changed, 295 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 36aac88..3d86bc6 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -2070,6 +2070,7 @@ struct megasas_instance {
>   /* used to sync fire the cmd to fw */
>   spinlock_t hba_lock;
>   /* used to synch producer, consumer ptrs in dpc */
> + spinlock_t stream_lock;
>   spinlock_t completion_lock;
>   struct dma_pool *frame_dma_pool;
>   struct dma_pool *sense_dma_pool;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 5a1a53b..8e20992 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5001,7 +5001,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   struct megasas_register_set __iomem *reg_set;
>   struct megasas_ctrl_info *ctrl_info = NULL;
>   unsigned long bar_list;
> - int i, loop, fw_msix_count = 0;
> + int i, j, loop, fw_msix_count = 0;
>   struct IOV_111 *iovPtr;
>   struct fusion_context *fusion;
>  
> @@ -5194,6 +5194,36 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   }
>  
>   memset(instance->ld_ids, 0xff, MEGASAS_MAX_LD_IDS);
> +
> + /* stream detection initialization */
> + if (instance->is_ventura) {
> + fusion->stream_detect_by_ld =
> + kzalloc(sizeof(struct LD_STREAM_DETECT *)
> + * MAX_LOGICAL_DRIVES_EXT,
> + GFP_KERNEL);
> + if (!fusion->stream_detect_by_ld) {
> + dev_err(>pdev->dev,
> + "unable to allocate stream detection 
> for pool of LDs\n");
> + goto fail_get_ld_pd_list;
> + }
> + for (i = 0; i < MAX_LOGICAL_DRIVES_EXT; ++i) {
> + fusion->stream_detect_by_ld[i] =
> + kmalloc(sizeof(struct LD_STREAM_DETECT),
> + GFP_KERNEL);
> + if (!fusion->stream_detect_by_ld[i]) {
> + dev_err(>pdev->dev,
> + "unable to allocate stream detect by 
> LD\n ");
> +  for (j = 0; j < i; ++j)
> + kfree(fusion->stream_detect_by_ld[j]);
> + kfree(fusion->stream_detect_by_ld);
> + fusion->stream_detect_by_ld = NULL;
> + goto fail_get_ld_pd_list;
> + }
> + fusion->stream_detect_by_ld[i]->mru_bit_map
> + = MR_STREAM_BITMAP;
> + }
> + }
> +
>   if (megasas_ld_list_query(instance,
> MR_LD_QUERY_TYPE_EXPOSED_TO_HOST))
>   megasas_get_ld_list(instance);
> @@ -5313,6 +5343,8 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  
>   return 0;
>  
> +fail_get_ld_pd_list:
> + instance->instancet->disable_intr(instance);
>  fail_get_pd_list:
>   instance->instancet->disable_intr(instance);
>  fail_init_adapter:
> @@ -5846,6 +5878,7 @@ static int megasas_probe_one(struct pci_dev *pdev,
>  
>   spin_lock_init(>mfi_pool_lock);
>   spin_lock_init(>hba_lock);
> + spin_lock_init(>stream_lock);
>   spin_lock_init(>completion_lock);
>  
>   mutex_init(>reset_mutex);
> @@ -6353,6 +6386,14 @@ static void megasas_detach_one(struct pci_dev *pdev)
>   if (instance->msix_vectors)
>

Re: [PATCH V4 04/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and IO Coalescing

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Detect sequential IO streams and pass those IOs directly to FW.
>
> This patch is depending on patch 3
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   5 +-
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  43 +++-
>  drivers/scsi/megaraid/megaraid_sas_fp.c |   2 +
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 164 
> +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 117 +++-
>  5 files changed, 298 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 9d4ca8d..d07b3e1 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -105,7 +105,7 @@
>   */
>  
>  /*
> - * MFI stands for  MegaRAID SAS FW Interface. This is just a moniker for 
> + * MFI stands for  MegaRAID SAS FW Interface. This is just a moniker for
>   * protocol between the software and firmware. Commands are issued using
>   * "message frames"
>   */
> @@ -1440,7 +1440,7 @@ enum FW_BOOT_CONTEXT {
>  * register set for both 1068 and 1078 controllers
>  * structure extended for 1078 registers
>  */
> - 
> +
>  struct megasas_register_set {
>   u32 doorbell;   /*h*/
>   u32 fusion_seq_offset;  /*0004h*/
> @@ -2070,6 +2070,7 @@ struct megasas_instance {
>   /* used to sync fire the cmd to fw */
>   spinlock_t hba_lock;
>   /* used to synch producer, consumer ptrs in dpc */
> + spinlock_t stream_lock;
>   spinlock_t completion_lock;
>   struct dma_pool *frame_dma_pool;
>   struct dma_pool *sense_dma_pool;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index c583e0b..c52f7be 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5015,7 +5015,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   struct megasas_register_set __iomem *reg_set;
>   struct megasas_ctrl_info *ctrl_info = NULL;
>   unsigned long bar_list;
> - int i, loop, fw_msix_count = 0;
> + int i, j, loop, fw_msix_count = 0;
>   struct IOV_111 *iovPtr;
>   struct fusion_context *fusion;
>  
> @@ -5202,6 +5202,36 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   }
>  
>   memset(instance->ld_ids, 0xff, MEGASAS_MAX_LD_IDS);
> +
> + /* stream detection initialization */
> + if (instance->is_ventura) {
> + fusion->stream_detect_by_ld =
> + kzalloc(sizeof(struct LD_STREAM_DETECT *)
> + * MAX_LOGICAL_DRIVES_EXT,
> + GFP_KERNEL);
> + if (!fusion->stream_detect_by_ld) {
> + dev_err(>pdev->dev,
> + "unable to allocate stream detection 
> for pool of LDs\n");
> + goto fail_get_ld_pd_list;
> + }
> + for (i = 0; i < MAX_LOGICAL_DRIVES_EXT; ++i) {
> + fusion->stream_detect_by_ld[i] =
> + kmalloc(sizeof(struct LD_STREAM_DETECT),
> + GFP_KERNEL);
> + if (!fusion->stream_detect_by_ld[i]) {
> + dev_err(>pdev->dev,
> + "unable to allocate stream detect by 
> LD\n ");
> +  for (j = 0; j < i; ++j)
> + kfree(fusion->stream_detect_by_ld[j]);
> + kfree(fusion->stream_detect_by_ld);
> + fusion->stream_detect_by_ld = NULL;
> + goto fail_get_ld_pd_list;
> + }
> + fusion->stream_detect_by_ld[i]->mru_bit_map
> + = MR_STREAM_BITMAP;
> + }
> + }
> +
>   if (megasas_ld_list_query(instance,
> MR_LD_QUERY_TYPE_EXPOSED_TO_HOST))
>   megasas_get_ld_list(instance);
> @@ -5321,6 +5351,8 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  
>   return 0;
>  
> +fail_get_ld_pd_list:
> + instance->instancet->disable_intr(instance);
>  fail_get_pd_list:
>   instance->instancet->disable_intr(instance);
>   megasas_destroy_irqs(instance);
> @@ -5854,6 +5886,7 @@ static int megasas_probe_one(struct pci_dev *pdev,
>  
>   spin_lock_init(>mfi_pool_lock);
>   spin_lock_init(>hba_lock);
> + spin_lock_init(>stream_lock);
>   spin_lock_init(>completion_lock);
>  
>   mutex_init(>reset_mutex);
> @@ -6354,6 +6387,14 @@ static void megasas_detach_one(struct pci_dev *pdev)
>   if (instance->msix_vectors)
>   pci_disable_msix(instance->pdev);
>  
> + if (instance->is_ventura) {
> + 

Re: [PATCH V4 04/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and IO Coalescing

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Detect sequential IO streams and pass those IOs directly to FW.
>
> This patch is depending on patch 3
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   5 +-
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  43 +++-
>  drivers/scsi/megaraid/megaraid_sas_fp.c |   2 +
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 164 
> +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 117 +++-
>  5 files changed, 298 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 9d4ca8d..d07b3e1 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -105,7 +105,7 @@
>   */
>  
>  /*
> - * MFI stands for  MegaRAID SAS FW Interface. This is just a moniker for 
> + * MFI stands for  MegaRAID SAS FW Interface. This is just a moniker for
>   * protocol between the software and firmware. Commands are issued using
>   * "message frames"
>   */
> @@ -1440,7 +1440,7 @@ enum FW_BOOT_CONTEXT {
>  * register set for both 1068 and 1078 controllers
>  * structure extended for 1078 registers
>  */
> - 
> +
>  struct megasas_register_set {
>   u32 doorbell;   /*h*/
>   u32 fusion_seq_offset;  /*0004h*/
> @@ -2070,6 +2070,7 @@ struct megasas_instance {
>   /* used to sync fire the cmd to fw */
>   spinlock_t hba_lock;
>   /* used to synch producer, consumer ptrs in dpc */
> + spinlock_t stream_lock;
>   spinlock_t completion_lock;
>   struct dma_pool *frame_dma_pool;
>   struct dma_pool *sense_dma_pool;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index c583e0b..c52f7be 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5015,7 +5015,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   struct megasas_register_set __iomem *reg_set;
>   struct megasas_ctrl_info *ctrl_info = NULL;
>   unsigned long bar_list;
> - int i, loop, fw_msix_count = 0;
> + int i, j, loop, fw_msix_count = 0;
>   struct IOV_111 *iovPtr;
>   struct fusion_context *fusion;
>  
> @@ -5202,6 +5202,36 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   }
>  
>   memset(instance->ld_ids, 0xff, MEGASAS_MAX_LD_IDS);
> +
> + /* stream detection initialization */
> + if (instance->is_ventura) {
> + fusion->stream_detect_by_ld =
> + kzalloc(sizeof(struct LD_STREAM_DETECT *)
> + * MAX_LOGICAL_DRIVES_EXT,
> + GFP_KERNEL);
> + if (!fusion->stream_detect_by_ld) {
> + dev_err(>pdev->dev,
> + "unable to allocate stream detection 
> for pool of LDs\n");
> + goto fail_get_ld_pd_list;
> + }
> + for (i = 0; i < MAX_LOGICAL_DRIVES_EXT; ++i) {
> + fusion->stream_detect_by_ld[i] =
> + kmalloc(sizeof(struct LD_STREAM_DETECT),
> + GFP_KERNEL);
> + if (!fusion->stream_detect_by_ld[i]) {
> + dev_err(>pdev->dev,
> + "unable to allocate stream detect by 
> LD\n ");
> +  for (j = 0; j < i; ++j)
> + kfree(fusion->stream_detect_by_ld[j]);
> + kfree(fusion->stream_detect_by_ld);
> + fusion->stream_detect_by_ld = NULL;
> + goto fail_get_ld_pd_list;
> + }
> + fusion->stream_detect_by_ld[i]->mru_bit_map
> + = MR_STREAM_BITMAP;
> + }
> + }
> +
>   if (megasas_ld_list_query(instance,
> MR_LD_QUERY_TYPE_EXPOSED_TO_HOST))
>   megasas_get_ld_list(instance);
> @@ -5321,6 +5351,8 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  
>   return 0;
>  
> +fail_get_ld_pd_list:
> + instance->instancet->disable_intr(instance);
>  fail_get_pd_list:
>   instance->instancet->disable_intr(instance);
>   megasas_destroy_irqs(instance);
> @@ -5854,6 +5886,7 @@ static int megasas_probe_one(struct pci_dev *pdev,
>  
>   spin_lock_init(>mfi_pool_lock);
>   spin_lock_init(>hba_lock);
> + spin_lock_init(>stream_lock);
>   spin_lock_init(>completion_lock);
>  
>   mutex_init(>reset_mutex);
> @@ -6354,6 +6387,14 @@ static void megasas_detach_one(struct pci_dev *pdev)
>   if (instance->msix_vectors)
>   pci_disable_msix(instance->pdev);
>  
> + if (instance->is_ventura) {
> + for (i = 0; i < 

Re: [PATCH V4 10/11] megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Update Linux driver to use new pdTargetId field for JBOD target ID
>
> This patch is depending on patch 9
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH V4 11/11] megaraid_sas: driver version upgrade

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Upgrade driver version.
>
> This patch is depending on patch 10
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>
> ---
>  drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 7334e07..310555a 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -35,8 +35,8 @@
>  /*
>   * MegaRAID SAS Driver meta data
>   */
> -#define MEGASAS_VERSION  "06.812.07.00-rc1"
> -#define MEGASAS_RELDATE  "August 22, 2016"
> +#define MEGASAS_VERSION  "07.700.00.00-rc1"
> +#define MEGASAS_RELDATE  "November 29, 2016"
>  
>  /*
>   * Device IDs

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH V4 10/11] megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Update Linux driver to use new pdTargetId field for JBOD target ID
>
> This patch is depending on patch 9
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH V4 11/11] megaraid_sas: driver version upgrade

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Upgrade driver version.
>
> This patch is depending on patch 10
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 7334e07..310555a 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -35,8 +35,8 @@
>  /*
>   * MegaRAID SAS Driver meta data
>   */
> -#define MEGASAS_VERSION  "06.812.07.00-rc1"
> -#define MEGASAS_RELDATE  "August 22, 2016"
> +#define MEGASAS_VERSION  "07.700.00.00-rc1"
> +#define MEGASAS_RELDATE  "November 29, 2016"
>  
>  /*
>   * Device IDs

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH V4 09/11] megaraid_sas: ldio_outstanding variable is not decremented in completion path

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> ldio outstanding variable needs to be decremented in io completion path for
> iMR dual queue depth
>
> This patch is depending on patch 8
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH V4 09/11] megaraid_sas: ldio_outstanding variable is not decremented in completion path

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> ldio outstanding variable needs to be decremented in io completion path for
> iMR dual queue depth
>
> This patch is depending on patch 8
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Large SEQ IO workload should sent as non fast path commands
>
> This patch is depending on patch 7
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48 
> +
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>  5 files changed, 78 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 3e087ab..eb5be2b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>  #define MFI_1068_FW_HANDSHAKE_OFFSET 0x64
>  #define MFI_1068_FW_READY0x
>  
> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
> +
>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>   atomic_t ldio_outstanding;
>   atomic_t fw_reset_no_pci_access;
>  
> + atomic64_t bytes_wrote; /* used for raid1 fast path enable or disable */
> + atomic_t r1_write_fp_capable;

Is a an atomic variable needed for a just boolean variable?

> +
> +
>   struct megasas_instance_template *instancet;
>   struct tasklet_struct isr_tasklet;
>   struct work_struct work_init;
> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>   long reset_flags;
>   struct mutex reset_mutex;
>   struct timer_list sriov_heartbeat_timer;
> + struct timer_list r1_fp_hold_timer;
>   char skip_heartbeat_timer_del;
>   u8 requestorId;
>   char PlasmaFW111;
> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>   bool is_ventura;
>   bool msix_combined;
>   u16 max_raid_mapsize;
> + u64 pci_threshold_bandwidth; /* used to control the fp writes */
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 8aafb59..899d25c 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance 
> *instance)
>   }
>   /* Complete outstanding ioctls when adapter is killed */
>   megasas_complete_outstanding_ioctls(instance);
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>  }
>  
>   /**
> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned long 
> instance_addr)
>   }
>  }
>  
> +/*Handler for disabling/enabling raid 1 fast paths*/
> +void megasas_change_r1_fp_status(unsigned long instance_addr)
> +{
> + struct megasas_instance *instance =
> + (struct megasas_instance *)instance_addr;
> + if (atomic64_read(>bytes_wrote) >=
> + instance->pci_threshold_bandwidth) {
> +
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 0);
> + } else {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + }
> + mod_timer(>r1_fp_hold_timer,
> +  jiffies + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> +}
> +
>  /**
>   * megasas_wait_for_outstanding -Wait for all outstanding cmds
>   * @instance:Adapter soft state
> @@ -5371,6 +5392,17 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   instance->skip_heartbeat_timer_del = 1;
>   }
>  
> + if (instance->is_ventura) {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + megasas_start_timer(instance,
> + >r1_fp_hold_timer,
> + megasas_change_r1_fp_status,
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + dev_info(>pdev->dev, "starting the 
> raid 1 fp timer with interval %d\n",
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + }
> +
>   return 0;
>  
>  fail_get_ld_pd_list:
> @@ -6161,6 +6193,9 @@ static void megasas_shutdown_controller(struct 
> megasas_instance *instance,
>   if (instance->requestorId && !instance->skip_heartbeat_timer_del)
>   del_timer_sync(>sriov_heartbeat_timer);
>  
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>   megasas_flush_cache(instance);
>   megasas_shutdown_controller(instance, MR_DCMD_HIBERNATE_SHUTDOWN);
>  
> @@ -6280,6 +6315,16 @@ 

Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Large SEQ IO workload should sent as non fast path commands
>
> This patch is depending on patch 7
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48 
> +
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>  5 files changed, 78 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 3e087ab..eb5be2b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>  #define MFI_1068_FW_HANDSHAKE_OFFSET 0x64
>  #define MFI_1068_FW_READY0x
>  
> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
> +
>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>   atomic_t ldio_outstanding;
>   atomic_t fw_reset_no_pci_access;
>  
> + atomic64_t bytes_wrote; /* used for raid1 fast path enable or disable */
> + atomic_t r1_write_fp_capable;

Is a an atomic variable needed for a just boolean variable?

> +
> +
>   struct megasas_instance_template *instancet;
>   struct tasklet_struct isr_tasklet;
>   struct work_struct work_init;
> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>   long reset_flags;
>   struct mutex reset_mutex;
>   struct timer_list sriov_heartbeat_timer;
> + struct timer_list r1_fp_hold_timer;
>   char skip_heartbeat_timer_del;
>   u8 requestorId;
>   char PlasmaFW111;
> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>   bool is_ventura;
>   bool msix_combined;
>   u16 max_raid_mapsize;
> + u64 pci_threshold_bandwidth; /* used to control the fp writes */
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 8aafb59..899d25c 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance 
> *instance)
>   }
>   /* Complete outstanding ioctls when adapter is killed */
>   megasas_complete_outstanding_ioctls(instance);
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>  }
>  
>   /**
> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned long 
> instance_addr)
>   }
>  }
>  
> +/*Handler for disabling/enabling raid 1 fast paths*/
> +void megasas_change_r1_fp_status(unsigned long instance_addr)
> +{
> + struct megasas_instance *instance =
> + (struct megasas_instance *)instance_addr;
> + if (atomic64_read(>bytes_wrote) >=
> + instance->pci_threshold_bandwidth) {
> +
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 0);
> + } else {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + }
> + mod_timer(>r1_fp_hold_timer,
> +  jiffies + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> +}
> +
>  /**
>   * megasas_wait_for_outstanding -Wait for all outstanding cmds
>   * @instance:Adapter soft state
> @@ -5371,6 +5392,17 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   instance->skip_heartbeat_timer_del = 1;
>   }
>  
> + if (instance->is_ventura) {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + megasas_start_timer(instance,
> + >r1_fp_hold_timer,
> + megasas_change_r1_fp_status,
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + dev_info(>pdev->dev, "starting the 
> raid 1 fp timer with interval %d\n",
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + }
> +
>   return 0;
>  
>  fail_get_ld_pd_list:
> @@ -6161,6 +6193,9 @@ static void megasas_shutdown_controller(struct 
> megasas_instance *instance,
>   if (instance->requestorId && !instance->skip_heartbeat_timer_del)
>   del_timer_sync(>sriov_heartbeat_timer);
>  
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>   megasas_flush_cache(instance);
>   megasas_shutdown_controller(instance, MR_DCMD_HIBERNATE_SHUTDOWN);
>  
> @@ -6280,6 +6315,16 @@ static void 

Re: [PATCH V4 07/11] megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers Capabilities

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> The Megaraid driver has to support the SAS3.5 Generic Megaraid Controllers 
> Firmware functionality.
>
> This patch is depending on patch 6
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 53 
> ++---
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 19 ++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h |  1 +
>  3 files changed, 37 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 3f06b57..8aafb59 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5057,34 +5057,29 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  
>   reg_set = instance->reg_set;
>  
> - switch (instance->pdev->device) {
> - case PCI_DEVICE_ID_LSI_FUSION:
> - case PCI_DEVICE_ID_LSI_PLASMA:
> - case PCI_DEVICE_ID_LSI_INVADER:
> - case PCI_DEVICE_ID_LSI_FURY:
> - case PCI_DEVICE_ID_LSI_INTRUDER:
> - case PCI_DEVICE_ID_LSI_INTRUDER_24:
> - case PCI_DEVICE_ID_LSI_CUTLASS_52:
> - case PCI_DEVICE_ID_LSI_CUTLASS_53:
> + if (fusion)
>   instance->instancet = _instance_template_fusion;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1078R:
> - case PCI_DEVICE_ID_LSI_SAS1078DE:
> - instance->instancet = _instance_template_ppc;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1078GEN2:
> - case PCI_DEVICE_ID_LSI_SAS0079GEN2:
> - instance->instancet = _instance_template_gen2;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
> - case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
> - instance->instancet = _instance_template_skinny;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1064R:
> - case PCI_DEVICE_ID_DELL_PERC5:
> - default:
> - instance->instancet = _instance_template_xscale;
> - break;
> + else {
> + switch (instance->pdev->device) {
> + case PCI_DEVICE_ID_LSI_SAS1078R:
> + case PCI_DEVICE_ID_LSI_SAS1078DE:
> + instance->instancet = _instance_template_ppc;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS1078GEN2:
> + case PCI_DEVICE_ID_LSI_SAS0079GEN2:
> + instance->instancet = _instance_template_gen2;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
> + case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
> + instance->instancet = _instance_template_skinny;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS1064R:
> + case PCI_DEVICE_ID_DELL_PERC5:
> + default:
> + instance->instancet = _instance_template_xscale;
> + instance->pd_list_not_supported = 1;
> + break;
> + }
>   }
>  
>   if (megasas_transition_to_ready(instance, 0)) {
> @@ -5828,7 +5823,9 @@ static int megasas_probe_one(struct pci_dev *pdev,
>   if ((instance->pdev->device == PCI_DEVICE_ID_LSI_FUSION) ||
>   (instance->pdev->device == PCI_DEVICE_ID_LSI_PLASMA))
>   fusion->adapter_type = THUNDERBOLT_SERIES;
> - else if (!instance->is_ventura)
> + else if (instance->is_ventura)
> + fusion->adapter_type = VENTURA_SERIES;
> + else
>   fusion->adapter_type = INVADER_SERIES;
>   }
>   break;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index 58f86aa..f968a23 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -244,7 +244,10 @@ inline void megasas_return_cmd_fusion(struct 
> megasas_instance *instance,
>  
>   reg_set = instance->reg_set;
>  
> - cur_max_fw_cmds = readl(>reg_set->outbound_scratch_pad_3) & 
> 0x00;
> + /* ventura FW does not fill outbound_scratch_pad_3 with queue depth */
> + if (!instance->is_ventura)
> + cur_max_fw_cmds =
> + readl(>reg_set->outbound_scratch_pad_3) & 0x00;
>  
>   if (dual_qdepth_disable || !cur_max_fw_cmds)

This test connected with the fact that ventura skips reading cur_max_fw_cmds
makes using ventura equal to "dual_qdepth_disable == 1" so ldio_threshold is 
not set.
Is that intentional?

tomash 

>   cur_max_fw_cmds = 
> instance->instancet->read_fw_status_reg(reg_set) & 0x00;
> @@ -843,7 +846,7 @@ static int megasas_create_sg_sense_fusion(struct 
> megasas_instance *instance)
>   drv_ops = (MFI_CAPABILITIES *) &(init_frame->driver_operations);
>  
>   /* driver support Extended MSIX */
> - if (fusion->adapter_type 

Re: [PATCH V4 07/11] megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers Capabilities

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> The Megaraid driver has to support the SAS3.5 Generic Megaraid Controllers 
> Firmware functionality.
>
> This patch is depending on patch 6
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 53 
> ++---
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 19 ++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h |  1 +
>  3 files changed, 37 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 3f06b57..8aafb59 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5057,34 +5057,29 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  
>   reg_set = instance->reg_set;
>  
> - switch (instance->pdev->device) {
> - case PCI_DEVICE_ID_LSI_FUSION:
> - case PCI_DEVICE_ID_LSI_PLASMA:
> - case PCI_DEVICE_ID_LSI_INVADER:
> - case PCI_DEVICE_ID_LSI_FURY:
> - case PCI_DEVICE_ID_LSI_INTRUDER:
> - case PCI_DEVICE_ID_LSI_INTRUDER_24:
> - case PCI_DEVICE_ID_LSI_CUTLASS_52:
> - case PCI_DEVICE_ID_LSI_CUTLASS_53:
> + if (fusion)
>   instance->instancet = _instance_template_fusion;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1078R:
> - case PCI_DEVICE_ID_LSI_SAS1078DE:
> - instance->instancet = _instance_template_ppc;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1078GEN2:
> - case PCI_DEVICE_ID_LSI_SAS0079GEN2:
> - instance->instancet = _instance_template_gen2;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
> - case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
> - instance->instancet = _instance_template_skinny;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1064R:
> - case PCI_DEVICE_ID_DELL_PERC5:
> - default:
> - instance->instancet = _instance_template_xscale;
> - break;
> + else {
> + switch (instance->pdev->device) {
> + case PCI_DEVICE_ID_LSI_SAS1078R:
> + case PCI_DEVICE_ID_LSI_SAS1078DE:
> + instance->instancet = _instance_template_ppc;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS1078GEN2:
> + case PCI_DEVICE_ID_LSI_SAS0079GEN2:
> + instance->instancet = _instance_template_gen2;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
> + case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
> + instance->instancet = _instance_template_skinny;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS1064R:
> + case PCI_DEVICE_ID_DELL_PERC5:
> + default:
> + instance->instancet = _instance_template_xscale;
> + instance->pd_list_not_supported = 1;
> + break;
> + }
>   }
>  
>   if (megasas_transition_to_ready(instance, 0)) {
> @@ -5828,7 +5823,9 @@ static int megasas_probe_one(struct pci_dev *pdev,
>   if ((instance->pdev->device == PCI_DEVICE_ID_LSI_FUSION) ||
>   (instance->pdev->device == PCI_DEVICE_ID_LSI_PLASMA))
>   fusion->adapter_type = THUNDERBOLT_SERIES;
> - else if (!instance->is_ventura)
> + else if (instance->is_ventura)
> + fusion->adapter_type = VENTURA_SERIES;
> + else
>   fusion->adapter_type = INVADER_SERIES;
>   }
>   break;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index 58f86aa..f968a23 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -244,7 +244,10 @@ inline void megasas_return_cmd_fusion(struct 
> megasas_instance *instance,
>  
>   reg_set = instance->reg_set;
>  
> - cur_max_fw_cmds = readl(>reg_set->outbound_scratch_pad_3) & 
> 0x00;
> + /* ventura FW does not fill outbound_scratch_pad_3 with queue depth */
> + if (!instance->is_ventura)
> + cur_max_fw_cmds =
> + readl(>reg_set->outbound_scratch_pad_3) & 0x00;
>  
>   if (dual_qdepth_disable || !cur_max_fw_cmds)

This test connected with the fact that ventura skips reading cur_max_fw_cmds
makes using ventura equal to "dual_qdepth_disable == 1" so ldio_threshold is 
not set.
Is that intentional?

tomash 

>   cur_max_fw_cmds = 
> instance->instancet->read_fw_status_reg(reg_set) & 0x00;
> @@ -843,7 +846,7 @@ static int megasas_create_sg_sense_fusion(struct 
> megasas_instance *instance)
>   drv_ops = (MFI_CAPABILITIES *) &(init_frame->driver_operations);
>  
>   /* driver support Extended MSIX */
> - if (fusion->adapter_type == INVADER_SERIES)
> + 

Re: [PATCH V4 07/11] megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers Capabilities

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> The Megaraid driver has to support the SAS3.5 Generic Megaraid Controllers 
> Firmware functionality.
>
> This patch is depending on patch 6
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH V4 07/11] megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers Capabilities

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> The Megaraid driver has to support the SAS3.5 Generic Megaraid Controllers 
> Firmware functionality.
>
> This patch is depending on patch 6
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap to 
> have different
> sizes for different number of supported VDs.
>
> This patch is depending on patch 5
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   7 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  61 --
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 303 
> 
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 223 
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 240 ++
>  5 files changed, 699 insertions(+), 135 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index f4d6a94..3e087ab 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1434,6 +1434,12 @@ enum FW_BOOT_CONTEXT {
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>  #define MR_MAX_MSIX_REG_ARRAY   16
>  #define MR_RDPQ_MODE_OFFSET  0X0080
> +
> +#define MR_MAX_RAID_MAP_SIZE_OFFSET_SHIFT16
> +#define MR_MAX_RAID_MAP_SIZE_MASK0x1FF
> +#define MR_MIN_MAP_SIZE  0x1
> +/* 64k */
> +
>  #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET  0X0100
>  
>  /*
> @@ -2152,6 +2158,7 @@ struct megasas_instance {
>   bool fw_sync_cache_support;
>   bool is_ventura;
>   bool msix_combined;
> + u16 max_raid_mapsize;
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index c52f7be..3f06b57 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance 
> *instance)
>  static void megasas_update_ext_vd_details(struct megasas_instance *instance)
>  {
>   struct fusion_context *fusion;
> - u32 old_map_sz;
> - u32 new_map_sz;
> + u32 ventura_map_sz = 0;
>  
>   fusion = instance->ctrl_context;
>   /* For MFI based controllers return dummy success */
> @@ -4455,21 +4454,39 @@ static void megasas_update_ext_vd_details(struct 
> megasas_instance *instance)
>   instance->supportmax256vd ? "Extended VD(240 VD)firmware" :
>   "Legacy(64 VD) firmware");
>  
> - old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->fw_supported_vd_count - 1));
> - new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
> - fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->drv_supported_vd_count - 1));
> -
> - fusion->max_map_sz = max(old_map_sz, new_map_sz);
> + if (instance->max_raid_mapsize) {
> + ventura_map_sz = instance->max_raid_mapsize *
> + MR_MIN_MAP_SIZE; /* 64k */
> + fusion->current_map_sz = ventura_map_sz;
> + fusion->max_map_sz = ventura_map_sz;
> + } else {
> + fusion->old_map_sz =  sizeof(struct MR_FW_RAID_MAP) +
> + (sizeof(struct MR_LD_SPAN_MAP) *
> + (instance->fw_supported_vd_count - 1));
> + fusion->new_map_sz =  sizeof(struct MR_FW_RAID_MAP_EXT);
>  
> + fusion->max_map_sz =
> + max(fusion->old_map_sz, fusion->new_map_sz);
>  
> - if (instance->supportmax256vd)
> - fusion->current_map_sz = new_map_sz;
> - else
> - fusion->current_map_sz = old_map_sz;
> + if (instance->supportmax256vd)
> + fusion->current_map_sz = fusion->new_map_sz;
> + else
> + fusion->current_map_sz = fusion->old_map_sz;
> + }
> + /* irrespective of FW raid maps, driver raid map is constant */
> + fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP_ALL);
> +#if VD_EXT_DEBUG
> + dev_info(>pdev->dev, "instance->max_raid_mapsize 0x%x \n ",
> + instance->max_raid_mapsize);
> + dev_info(>pdev->dev,
> + "new_map_sz = 0x%x, old_map_sz = 0x%x, "
> + "ventura_map_sz = 0x%x, current_map_sz = 0x%x "
> + "fusion->drv_map_sz =0x%x, size of driver raid map 0x%lx\n",
> + fusion->new_map_sz, fusion->old_map_sz,
> + ventura_map_sz, fusion->current_map_sz,
> + fusion->drv_map_sz,
> + sizeof(struct MR_DRV_RAID_MAP_ALL));
> +#endif
>  }
>  
>  /**
> @@ -5010,7 +5027,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  {
>   u32 max_sectors_1;
>   u32 max_sectors_2;
> - u32 tmp_sectors, msix_enable, scratch_pad_2;
> + u32 tmp_sectors, 

Re: [PATCH V4 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap to 
> have different
> sizes for different number of supported VDs.
>
> This patch is depending on patch 5
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   7 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  61 --
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 303 
> 
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 223 
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 240 ++
>  5 files changed, 699 insertions(+), 135 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index f4d6a94..3e087ab 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1434,6 +1434,12 @@ enum FW_BOOT_CONTEXT {
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>  #define MR_MAX_MSIX_REG_ARRAY   16
>  #define MR_RDPQ_MODE_OFFSET  0X0080
> +
> +#define MR_MAX_RAID_MAP_SIZE_OFFSET_SHIFT16
> +#define MR_MAX_RAID_MAP_SIZE_MASK0x1FF
> +#define MR_MIN_MAP_SIZE  0x1
> +/* 64k */
> +
>  #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET  0X0100
>  
>  /*
> @@ -2152,6 +2158,7 @@ struct megasas_instance {
>   bool fw_sync_cache_support;
>   bool is_ventura;
>   bool msix_combined;
> + u16 max_raid_mapsize;
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index c52f7be..3f06b57 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance 
> *instance)
>  static void megasas_update_ext_vd_details(struct megasas_instance *instance)
>  {
>   struct fusion_context *fusion;
> - u32 old_map_sz;
> - u32 new_map_sz;
> + u32 ventura_map_sz = 0;
>  
>   fusion = instance->ctrl_context;
>   /* For MFI based controllers return dummy success */
> @@ -4455,21 +4454,39 @@ static void megasas_update_ext_vd_details(struct 
> megasas_instance *instance)
>   instance->supportmax256vd ? "Extended VD(240 VD)firmware" :
>   "Legacy(64 VD) firmware");
>  
> - old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->fw_supported_vd_count - 1));
> - new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
> - fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->drv_supported_vd_count - 1));
> -
> - fusion->max_map_sz = max(old_map_sz, new_map_sz);
> + if (instance->max_raid_mapsize) {
> + ventura_map_sz = instance->max_raid_mapsize *
> + MR_MIN_MAP_SIZE; /* 64k */
> + fusion->current_map_sz = ventura_map_sz;
> + fusion->max_map_sz = ventura_map_sz;
> + } else {
> + fusion->old_map_sz =  sizeof(struct MR_FW_RAID_MAP) +
> + (sizeof(struct MR_LD_SPAN_MAP) *
> + (instance->fw_supported_vd_count - 1));
> + fusion->new_map_sz =  sizeof(struct MR_FW_RAID_MAP_EXT);
>  
> + fusion->max_map_sz =
> + max(fusion->old_map_sz, fusion->new_map_sz);
>  
> - if (instance->supportmax256vd)
> - fusion->current_map_sz = new_map_sz;
> - else
> - fusion->current_map_sz = old_map_sz;
> + if (instance->supportmax256vd)
> + fusion->current_map_sz = fusion->new_map_sz;
> + else
> + fusion->current_map_sz = fusion->old_map_sz;
> + }
> + /* irrespective of FW raid maps, driver raid map is constant */
> + fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP_ALL);
> +#if VD_EXT_DEBUG
> + dev_info(>pdev->dev, "instance->max_raid_mapsize 0x%x \n ",
> + instance->max_raid_mapsize);
> + dev_info(>pdev->dev,
> + "new_map_sz = 0x%x, old_map_sz = 0x%x, "
> + "ventura_map_sz = 0x%x, current_map_sz = 0x%x "
> + "fusion->drv_map_sz =0x%x, size of driver raid map 0x%lx\n",
> + fusion->new_map_sz, fusion->old_map_sz,
> + ventura_map_sz, fusion->current_map_sz,
> + fusion->drv_map_sz,
> + sizeof(struct MR_DRV_RAID_MAP_ALL));
> +#endif
>  }
>  
>  /**
> @@ -5010,7 +5027,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  {
>   u32 max_sectors_1;
>   u32 max_sectors_2;
> - u32 tmp_sectors, msix_enable, scratch_pad_2;
> + u32 tmp_sectors, msix_enable, scratch_pad_2, 

Re: [PATCH V4 05/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID 1/10 Writes

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> To improve RAID 1/10 Write performance, OS drivers need to issue the required 
> Write
> IOs as Fast Path IOs (after the appropriate checks allowing Fast Path to be 
> used)
> to the appropriate physical drives (translated from the OS logical IO) and 
> wait for
> all Write IOs to complete.  If any of the Write IOs fail or time out, the IO 
> will be
> re issued to FW as an LD IO so FW can perform the error handling.
>
> This patch is depending on patch 4
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH V4 05/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID 1/10 Writes

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> To improve RAID 1/10 Write performance, OS drivers need to issue the required 
> Write
> IOs as Fast Path IOs (after the appropriate checks allowing Fast Path to be 
> used)
> to the appropriate physical drives (translated from the OS logical IO) and 
> wait for
> all Write IOs to complete.  If any of the Write IOs fail or time out, the IO 
> will be
> re issued to FW as an LD IO so FW can perform the error handling.
>
> This patch is depending on patch 4
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH V4 04/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and IO Coalescing

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Detect sequential IO streams and pass those IOs directly to FW.
>
> This patch is depending on patch 3
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

Indentation in megasas_stream_detect is wrong on several places,
but ok for now.

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH V4 04/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and IO Coalescing

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Detect sequential IO streams and pass those IOs directly to FW.
>
> This patch is depending on patch 3
>
> Signed-off-by: Sasikumar Chandrasekaran 

Indentation in megasas_stream_detect is wrong on several places,
but ok for now.

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH V4 03/11] megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> An UNMAP command on a PI formatted device will leave the Logical Block 
> Application
> Tag and Logical Block Reference Tag as all F's (for those LBAs that are 
> unmapped).
> To avoid IO errors if those LBAs are subsequently read before they are 
> written with
> valid tag fields, the MPI SCSI IO requests need to set the EEDPFlags element 
> EEDP
> Escape Mode field, Bits [7:6] appropriately.  A value of 2 should be set to 
> disable
> all PI checks if the Logical Block Application Tag is 0x for PI types 1 
> and 2.
> A value of 3 should be set to disable all PI checks if the Logical Block 
> Application
> Tag is 0x and the Logical Block Reference Tag is 0x for PI type 3.
>
> This patch is depending on patch 2
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH V4 03/11] megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> An UNMAP command on a PI formatted device will leave the Logical Block 
> Application
> Tag and Logical Block Reference Tag as all F's (for those LBAs that are 
> unmapped).
> To avoid IO errors if those LBAs are subsequently read before they are 
> written with
> valid tag fields, the MPI SCSI IO requests need to set the EEDPFlags element 
> EEDP
> Escape Mode field, Bits [7:6] appropriately.  A value of 2 should be set to 
> disable
> all PI checks if the Logical Block Application Tag is 0x for PI types 1 
> and 2.
> A value of 3 should be set to disable all PI checks if the Logical Block 
> Application
> Tag is 0x and the Logical Block Reference Tag is 0x for PI type 3.
>
> This patch is depending on patch 2
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid based Controllers will have the support for 128 MSI-X 
> vectors,
> resulting in the need to support 128 reply queues
>
> This patch is depending on patch 1
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|  1 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 24 +---
>  drivers/scsi/megaraid/megaraid_sas_fusion.c |  4 ++--
>  3 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 72e16c2..9d4ca8d 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -2149,6 +2149,7 @@ struct megasas_instance {
>   bool dev_handle;
>   bool fw_sync_cache_support;
>   bool is_ventura;
> + bool msix_combined;
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index efccf98..c583e0b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5086,13 +5086,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   goto fail_ready_state;
>   }
>  
> - /*
> -  * MSI-X host index 0 is common for all adapter.
> -  * It is used for all MPT based Adapters.
> -  */
> - instance->reply_post_host_index_addr[0] =
> - (u32 __iomem *)((u8 __iomem *)instance->reg_set +
> - MPI2_REPLY_POST_HOST_INDEX_OFFSET);
> +
>  
>   /* Check if MSI-X is supported while in ready state */
>   msix_enable = (instance->instancet->read_fw_status_reg(reg_set) &
> @@ -5110,6 +5104,9 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   instance->msix_vectors = ((scratch_pad_2
>   & MR_MAX_REPLY_QUEUES_EXT_OFFSET)
>   >> 
> MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT) + 1;
> + if (instance->msix_vectors > 16)
> + instance->msix_combined = true;
> +
>   if (rdpq_enable)
>   instance->is_rdpq = (scratch_pad_2 & 
> MR_RDPQ_MODE_OFFSET) ?
>   1 : 0;
> @@ -5143,6 +5140,19 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   else
>   instance->msix_vectors = 0;
>   }

Have you tested this patch with the pci=nomsi kernel option?
is it safe when msix_combined is true and pci_enable_msix_range
fails so instance->msix_vectors is zero?

tomash

> + /*
> +  * MSI-X host index 0 is common for all adapter.
> +  * It is used for all MPT based Adapters.
> +  */
> + if (instance->msix_combined) {
> + instance->reply_post_host_index_addr[0] =
> + (u32 *)((u8 *)instance->reg_set +
> + MPI2_SUP_REPLY_POST_HOST_INDEX_OFFSET);
> + } else {
> + instance->reply_post_host_index_addr[0] =
> + (u32 *)((u8 *)instance->reg_set +
> + MPI2_REPLY_POST_HOST_INDEX_OFFSET);
> + }
>  
>   dev_info(>pdev->dev,
>   "firmware supports msix\t: (%d)", fw_msix_count);
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index 8d7a397..413e2030 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -2391,7 +2391,7 @@ static void megasas_build_ld_nonrw_fusion(struct 
> megasas_instance *instance,
>* pending to be completed
>*/
>   if (threshold_reply_count >= THRESHOLD_REPLY_COUNT) {
> - if (fusion->adapter_type == INVADER_SERIES)
> + if (instance->msix_combined)
>   writel(((MSIxIndex & 0x7) << 24) |
>   fusion->last_reply_idx[MSIxIndex],
>   
> instance->reply_post_host_index_addr[MSIxIndex/8]);
> @@ -2407,7 +2407,7 @@ static void megasas_build_ld_nonrw_fusion(struct 
> megasas_instance *instance,
>   return IRQ_NONE;
>  
>   wmb();
> - if (fusion->adapter_type == INVADER_SERIES)
> + if (instance->msix_combined)
>   writel(((MSIxIndex & 0x7) << 24) |
>   fusion->last_reply_idx[MSIxIndex],
>   instance->reply_post_host_index_addr[MSIxIndex/8]);

Re: [PATCH V4 02/11] megaraid_sas: 128 MSIX Support

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid based Controllers will have the support for 128 MSI-X 
> vectors,
> resulting in the need to support 128 reply queues
>
> This patch is depending on patch 1
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|  1 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 24 +---
>  drivers/scsi/megaraid/megaraid_sas_fusion.c |  4 ++--
>  3 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 72e16c2..9d4ca8d 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -2149,6 +2149,7 @@ struct megasas_instance {
>   bool dev_handle;
>   bool fw_sync_cache_support;
>   bool is_ventura;
> + bool msix_combined;
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index efccf98..c583e0b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5086,13 +5086,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   goto fail_ready_state;
>   }
>  
> - /*
> -  * MSI-X host index 0 is common for all adapter.
> -  * It is used for all MPT based Adapters.
> -  */
> - instance->reply_post_host_index_addr[0] =
> - (u32 __iomem *)((u8 __iomem *)instance->reg_set +
> - MPI2_REPLY_POST_HOST_INDEX_OFFSET);
> +
>  
>   /* Check if MSI-X is supported while in ready state */
>   msix_enable = (instance->instancet->read_fw_status_reg(reg_set) &
> @@ -5110,6 +5104,9 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   instance->msix_vectors = ((scratch_pad_2
>   & MR_MAX_REPLY_QUEUES_EXT_OFFSET)
>   >> 
> MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT) + 1;
> + if (instance->msix_vectors > 16)
> + instance->msix_combined = true;
> +
>   if (rdpq_enable)
>   instance->is_rdpq = (scratch_pad_2 & 
> MR_RDPQ_MODE_OFFSET) ?
>   1 : 0;
> @@ -5143,6 +5140,19 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   else
>   instance->msix_vectors = 0;
>   }

Have you tested this patch with the pci=nomsi kernel option?
is it safe when msix_combined is true and pci_enable_msix_range
fails so instance->msix_vectors is zero?

tomash

> + /*
> +  * MSI-X host index 0 is common for all adapter.
> +  * It is used for all MPT based Adapters.
> +  */
> + if (instance->msix_combined) {
> + instance->reply_post_host_index_addr[0] =
> + (u32 *)((u8 *)instance->reg_set +
> + MPI2_SUP_REPLY_POST_HOST_INDEX_OFFSET);
> + } else {
> + instance->reply_post_host_index_addr[0] =
> + (u32 *)((u8 *)instance->reg_set +
> + MPI2_REPLY_POST_HOST_INDEX_OFFSET);
> + }
>  
>   dev_info(>pdev->dev,
>   "firmware supports msix\t: (%d)", fw_msix_count);
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index 8d7a397..413e2030 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -2391,7 +2391,7 @@ static void megasas_build_ld_nonrw_fusion(struct 
> megasas_instance *instance,
>* pending to be completed
>*/
>   if (threshold_reply_count >= THRESHOLD_REPLY_COUNT) {
> - if (fusion->adapter_type == INVADER_SERIES)
> + if (instance->msix_combined)
>   writel(((MSIxIndex & 0x7) << 24) |
>   fusion->last_reply_idx[MSIxIndex],
>   
> instance->reply_post_host_index_addr[MSIxIndex/8]);
> @@ -2407,7 +2407,7 @@ static void megasas_build_ld_nonrw_fusion(struct 
> megasas_instance *instance,
>   return IRQ_NONE;
>  
>   wmb();
> - if (fusion->adapter_type == INVADER_SERIES)
> + if (instance->msix_combined)
>   writel(((MSIxIndex & 0x7) << 24) |
>   fusion->last_reply_idx[MSIxIndex],
>   instance->reply_post_host_index_addr[MSIxIndex/8]);

Re: [PATCH V4 01/11] megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> This patch contains new pci device ids for SAS3.5 Generic Megaraid Controllers
>
> V4: Removed the not supported PCI Device Ids
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>

The V4 does not panic my machine like the V3.

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH V4 01/11] megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> This patch contains new pci device ids for SAS3.5 Generic Megaraid Controllers
>
> V4: Removed the not supported PCI Device Ids
>
> Signed-off-by: Sasikumar Chandrasekaran 

The V4 does not panic my machine like the V3.

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH V3 01/11] megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 5.12.2016 17:27, Sasikumar Chandrasekaran wrote:
> This patch contains new pci device ids for SAS3.5 Generic Megaraid Controllers
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h| 11 ++-
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 20 ++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 30 
> ++---
>  3 files changed, 52 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 0d2625b..f24ce88 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -56,6 +56,14 @@
>  #define PCI_DEVICE_ID_LSI_INTRUDER_240x00cf
>  #define PCI_DEVICE_ID_LSI_CUTLASS_52 0x0052
>  #define PCI_DEVICE_ID_LSI_CUTLASS_53 0x0053
> +#define PCI_DEVICE_ID_LSI_MECTOR 0x00D4
> +#define PCI_DEVICE_ID_LSI_VENTURA0x0014
> +#define PCI_DEVICE_ID_LSI_CRUSADER   0x0015

Nack.

This is not good, my test system panics instead of booting.
megaraid_sas :02:0e.0: RDPQ mode: (disabled)
BUG: unable to handle kernel paging request at 1e78
IP: [] megasas_issue_init_mfi+0x171/0x270 [megaraid_sas]


you are already having a device with same device value in your pci_table  
(PCI_DEVICE_ID_DELL_PERC5 is also 0x15), so fix the switch in  
megasas_probe_one.

Cheers,
tomash


(when sending new fixed versions, please add to the changed patches a text 
explaining
what was changed in which version, like so - 
www.spinics.net/lists/linux-scsi/msg102122.html)


>  
> @@ -5723,6 +5732,15 @@ static int megasas_probe_one(struct pci_dev *pdev,
>   instance->pdev = pdev;
>  
>   switch (instance->pdev->device) {
> + case PCI_DEVICE_ID_LSI_VENTURA:
> + case PCI_DEVICE_ID_LSI_MARLIN:
> + case PCI_DEVICE_ID_LSI_MECTOR:
> + case PCI_DEVICE_ID_LSI_CRUSADER:
> + case PCI_DEVICE_ID_LSI_HARPOON:
> + case PCI_DEVICE_ID_LSI_TOMCAT:
> + case PCI_DEVICE_ID_LSI_VENTURA_4PORT:
> + case PCI_DEVICE_ID_LSI_CRUSADER_4PORT:
> +  instance->is_ventura = true;
>   case PCI_DEVICE_ID_LSI_FUSION:
>   case PCI_DEVICE_ID_LSI_PLASMA:
>   case PCI_DEVICE_ID_LSI_INVADER:

Re: [PATCH V3 01/11] megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 5.12.2016 17:27, Sasikumar Chandrasekaran wrote:
> This patch contains new pci device ids for SAS3.5 Generic Megaraid Controllers
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h| 11 ++-
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 20 ++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 30 
> ++---
>  3 files changed, 52 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 0d2625b..f24ce88 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -56,6 +56,14 @@
>  #define PCI_DEVICE_ID_LSI_INTRUDER_240x00cf
>  #define PCI_DEVICE_ID_LSI_CUTLASS_52 0x0052
>  #define PCI_DEVICE_ID_LSI_CUTLASS_53 0x0053
> +#define PCI_DEVICE_ID_LSI_MECTOR 0x00D4
> +#define PCI_DEVICE_ID_LSI_VENTURA0x0014
> +#define PCI_DEVICE_ID_LSI_CRUSADER   0x0015

Nack.

This is not good, my test system panics instead of booting.
megaraid_sas :02:0e.0: RDPQ mode: (disabled)
BUG: unable to handle kernel paging request at 1e78
IP: [] megasas_issue_init_mfi+0x171/0x270 [megaraid_sas]


you are already having a device with same device value in your pci_table  
(PCI_DEVICE_ID_DELL_PERC5 is also 0x15), so fix the switch in  
megasas_probe_one.

Cheers,
tomash


(when sending new fixed versions, please add to the changed patches a text 
explaining
what was changed in which version, like so - 
www.spinics.net/lists/linux-scsi/msg102122.html)


>  
> @@ -5723,6 +5732,15 @@ static int megasas_probe_one(struct pci_dev *pdev,
>   instance->pdev = pdev;
>  
>   switch (instance->pdev->device) {
> + case PCI_DEVICE_ID_LSI_VENTURA:
> + case PCI_DEVICE_ID_LSI_MARLIN:
> + case PCI_DEVICE_ID_LSI_MECTOR:
> + case PCI_DEVICE_ID_LSI_CRUSADER:
> + case PCI_DEVICE_ID_LSI_HARPOON:
> + case PCI_DEVICE_ID_LSI_TOMCAT:
> + case PCI_DEVICE_ID_LSI_VENTURA_4PORT:
> + case PCI_DEVICE_ID_LSI_CRUSADER_4PORT:
> +  instance->is_ventura = true;
>   case PCI_DEVICE_ID_LSI_FUSION:
>   case PCI_DEVICE_ID_LSI_PLASMA:
>   case PCI_DEVICE_ID_LSI_INVADER:

Re: [PATCH 00/11] Updates for scsi-next

[Tomas Henzl]

On 2.12.2016 15:07, Sasikumar Chandrasekaran wrote:
> Sasikumar Chandrasekaran (11):
>   megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: 128 MSIX Support
>   megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and
> IO Coalescing
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID
> 1/10 Writes
>   megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers
> Capabilities
>   megaraid_sas: Enable or Disable Fast path based on the PCI Threshold
> Bandwidth
>   megaraid_sas: ldio_outstanding variable is not decremented in
> completion path
>   megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: driver version upgrade
>
>  drivers/scsi/megaraid/megaraid_sas.h| 139 --
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 242 +++---
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 319 +++--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 687 
> 
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 318 -
>  5 files changed, 1474 insertions(+), 231 deletions(-)
>
Hi Sasikumar,

pleas run the scripts/checkpatch.pl script on your patch before sending,
it shows errors like this one

ERROR: DOS line endings
#80: FILE: drivers/scsi/megaraid/megaraid_sas.h:59:
+#define PCI_DEVICE_ID_LSI_MECTOR^I^I0x00D4^M$

>From my point of view there are too many checkpatch issues and the series
should be fixed.

Also when you resend the series add a version counting string V2 , V3 ...
to the mail subject so -> "[PATCH V2 00/11] Updates for scsi-next"


Thanks,
Tomas

Re: [PATCH 00/11] Updates for scsi-next

[Tomas Henzl]

On 2.12.2016 15:07, Sasikumar Chandrasekaran wrote:
> Sasikumar Chandrasekaran (11):
>   megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: 128 MSIX Support
>   megaraid_sas: EEDP Escape Mode Support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Stream Detection and
> IO Coalescing
>   megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID
> 1/10 Writes
>   megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers
> Capabilities
>   megaraid_sas: Enable or Disable Fast path based on the PCI Threshold
> Bandwidth
>   megaraid_sas: ldio_outstanding variable is not decremented in
> completion path
>   megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid
> Controllers
>   megaraid_sas: driver version upgrade
>
>  drivers/scsi/megaraid/megaraid_sas.h| 139 --
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 242 +++---
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 319 +++--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 687 
> 
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 318 -
>  5 files changed, 1474 insertions(+), 231 deletions(-)
>
Hi Sasikumar,

pleas run the scripts/checkpatch.pl script on your patch before sending,
it shows errors like this one

ERROR: DOS line endings
#80: FILE: drivers/scsi/megaraid/megaraid_sas.h:59:
+#define PCI_DEVICE_ID_LSI_MECTOR^I^I0x00D4^M$

>From my point of view there are too many checkpatch issues and the series
should be fixed.

Also when you resend the series add a version counting string V2 , V3 ...
to the mail subject so -> "[PATCH V2 00/11] Updates for scsi-next"


Thanks,
Tomas

Re: [PATCH v2] scsi: aic94xx: Add a missing call to kfree

[Tomas Henzl]

On 25.11.2016 13:23, Quentin Lambert wrote:
> Most error branches following the call to kzalloc contain
> a call to kfree. This patch add these calls where they are
> missing and set the relevant pointers to NULL.
>
> This issue was found with Hector.
>
> Signed-off-by: Quentin Lambert <lambert.quen...@gmail.com>

Looks good,
Reviewed-by: Tomas Henzl <the...@redhat.com>
Tomas

Re: [PATCH v2] scsi: aic94xx: Add a missing call to kfree

[Tomas Henzl]

On 25.11.2016 13:23, Quentin Lambert wrote:
> Most error branches following the call to kzalloc contain
> a call to kfree. This patch add these calls where they are
> missing and set the relevant pointers to NULL.
>
> This issue was found with Hector.
>
> Signed-off-by: Quentin Lambert 

Looks good,
Reviewed-by: Tomas Henzl 
Tomas

Re: [PATCH] scsi: pmcraid: Add missing resource releases

[Tomas Henzl]

On 19.11.2016 18:43, Quentin Lambert wrote:
> Most error branches following the call to pmcraid_get_free_cmd contain
> a call to pmcraid_return_cmd. This patch add these calls where they are
> missing.
>
> Moreover, most error branches following the call to class_create contain
> a call to class_destroy. This patch add these calls where they are
> missing.
>
> This issue was found with Hector.
>
> Signed-off-by: Quentin Lambert <lambert.quen...@gmail.com>

Looks good,
Reviewed-by: Tomas Henzl <the...@redhat.com>
Tomas

>
> ---
>  drivers/scsi/pmcraid.c |   10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> --- a/drivers/scsi/pmcraid.c
> +++ b/drivers/scsi/pmcraid.c
> @@ -3787,11 +3787,11 @@ static long pmcraid_ioctl_passthrough(
> direction);
>   if (rc) {
>   pmcraid_err("couldn't build passthrough ioadls\n");
> - goto out_free_buffer;
> + goto out_free_cmd;
>   }
>   } else if (request_size < 0) {
>   rc = -EINVAL;
> - goto out_free_buffer;
> + goto out_free_cmd;
>   }
>  
>   /* If data is being written into the device, copy the data from user
> @@ -3908,6 +3908,8 @@ out_handle_response:
>  
>  out_free_sglist:
>   pmcraid_release_passthrough_ioadls(cmd, request_size, direction);
> +
> +out_free_cmd:
>   pmcraid_return_cmd(cmd);
>  
>  out_free_buffer:
> @@ -6018,8 +6020,10 @@ static int __init pmcraid_init(void)
>  
>   error = pmcraid_netlink_init();
>  
> - if (error)
> + if (error) {
> + class_destroy(pmcraid_class);
>   goto out_unreg_chrdev;
> + }
>  
>   error = pci_register_driver(_driver);
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: pmcraid: Add missing resource releases

[Tomas Henzl]

On 19.11.2016 18:43, Quentin Lambert wrote:
> Most error branches following the call to pmcraid_get_free_cmd contain
> a call to pmcraid_return_cmd. This patch add these calls where they are
> missing.
>
> Moreover, most error branches following the call to class_create contain
> a call to class_destroy. This patch add these calls where they are
> missing.
>
> This issue was found with Hector.
>
> Signed-off-by: Quentin Lambert 

Looks good,
Reviewed-by: Tomas Henzl 
Tomas

>
> ---
>  drivers/scsi/pmcraid.c |   10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> --- a/drivers/scsi/pmcraid.c
> +++ b/drivers/scsi/pmcraid.c
> @@ -3787,11 +3787,11 @@ static long pmcraid_ioctl_passthrough(
> direction);
>   if (rc) {
>   pmcraid_err("couldn't build passthrough ioadls\n");
> - goto out_free_buffer;
> + goto out_free_cmd;
>   }
>   } else if (request_size < 0) {
>   rc = -EINVAL;
> - goto out_free_buffer;
> + goto out_free_cmd;
>   }
>  
>   /* If data is being written into the device, copy the data from user
> @@ -3908,6 +3908,8 @@ out_handle_response:
>  
>  out_free_sglist:
>   pmcraid_release_passthrough_ioadls(cmd, request_size, direction);
> +
> +out_free_cmd:
>   pmcraid_return_cmd(cmd);
>  
>  out_free_buffer:
> @@ -6018,8 +6020,10 @@ static int __init pmcraid_init(void)
>  
>   error = pmcraid_netlink_init();
>  
> - if (error)
> + if (error) {
> + class_destroy(pmcraid_class);
>   goto out_unreg_chrdev;
> + }
>  
>   error = pci_register_driver(_driver);
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: aic94xx: Add a missing call to kfree

[Tomas Henzl]

On 19.11.2016 18:40, Quentin Lambert wrote:
> Most error branches following the call to kzalloc contain
> a call to kfree. This patch add these calls where they are
> missing.
>
> This issue was found with Hector.

Hi Quentin,
most error branches also do set the freed pointer to NULL,
please do the same.

tomash

> Signed-off-by: Quentin Lambert 
>
> ---
>  drivers/scsi/aic94xx/aic94xx_hwi.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- a/drivers/scsi/aic94xx/aic94xx_hwi.c
> +++ b/drivers/scsi/aic94xx/aic94xx_hwi.c
> @@ -228,8 +228,10 @@ static int asd_init_scbs(struct asd_ha_s
>   bitmap_bytes = (asd_ha->seq.tc_index_bitmap_bits+7)/8;
>   bitmap_bytes = BITS_TO_LONGS(bitmap_bytes*8)*sizeof(unsigned long);
>   asd_ha->seq.tc_index_bitmap = kzalloc(bitmap_bytes, GFP_KERNEL);
> - if (!asd_ha->seq.tc_index_bitmap)
> + if (!asd_ha->seq.tc_index_bitmap) {
> + kfree(asd_ha->seq.tc_index_array);
>   return -ENOMEM;
> + }
>  
>   spin_lock_init(>tc_index_lock);
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: aic94xx: Add a missing call to kfree

[Tomas Henzl]

On 19.11.2016 18:40, Quentin Lambert wrote:
> Most error branches following the call to kzalloc contain
> a call to kfree. This patch add these calls where they are
> missing.
>
> This issue was found with Hector.

Hi Quentin,
most error branches also do set the freed pointer to NULL,
please do the same.

tomash

> Signed-off-by: Quentin Lambert 
>
> ---
>  drivers/scsi/aic94xx/aic94xx_hwi.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- a/drivers/scsi/aic94xx/aic94xx_hwi.c
> +++ b/drivers/scsi/aic94xx/aic94xx_hwi.c
> @@ -228,8 +228,10 @@ static int asd_init_scbs(struct asd_ha_s
>   bitmap_bytes = (asd_ha->seq.tc_index_bitmap_bits+7)/8;
>   bitmap_bytes = BITS_TO_LONGS(bitmap_bytes*8)*sizeof(unsigned long);
>   asd_ha->seq.tc_index_bitmap = kzalloc(bitmap_bytes, GFP_KERNEL);
> - if (!asd_ha->seq.tc_index_bitmap)
> + if (!asd_ha->seq.tc_index_bitmap) {
> + kfree(asd_ha->seq.tc_index_array);
>   return -ENOMEM;
> + }
>  
>   spin_lock_init(>tc_index_lock);
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/10] mpt3sas: Fix for improper info displayed in var log, while blocking or unblocking the device.

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> Return value and Device_handle Arguments passed in correct order
>  to match with its format string.
>
> Signed-off-by: Chaitra P B <chaitra.basa...@broadcom.com>
> Signed-off-by: Sathya Prakash <sathya.prak...@broadcom.com>
> Signed-off-by: Suganath Prabu S <suganath-prabu.subram...@broadcom.com>
> ---

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH 01/10] mpt3sas: Fix for improper info displayed in var log, while blocking or unblocking the device.

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> Return value and Device_handle Arguments passed in correct order
>  to match with its format string.
>
> Signed-off-by: Chaitra P B 
> Signed-off-by: Sathya Prakash 
> Signed-off-by: Suganath Prabu S 
> ---

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH 10/10] mpt3sas: Fix for Endianness issue.

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> Use le16_to_cpu only for accessing two byte data provided by controller.
>
> Signed-off-by: Chaitra P B <chaitra.basa...@broadcom.com>
> Signed-off-by: Sathya Prakash <sathya.prak...@broadcom.com>
> Signed-off-by: Suganath Prabu S <suganath-prabu.subram...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH 10/10] mpt3sas: Fix for Endianness issue.

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> Use le16_to_cpu only for accessing two byte data provided by controller.
>
> Signed-off-by: Chaitra P B 
> Signed-off-by: Sathya Prakash 
> Signed-off-by: Suganath Prabu S 

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH 09/10] mpt3sas: Use the new MPI 2.6 32-bit Atomic Request Descriptors for SAS35 devices.

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> Support Atomic Request Descriptors for Ventura/SAS35 devices.
>
> Signed-off-by: Chaitra P B <chaitra.basa...@broadcom.com>
> Signed-off-by: Sathya Prakash <sathya.prak...@broadcom.com>
> Signed-off-by: Suganath Prabu S <suganath-prabu.subram...@broadcom.com>
> ---

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH 09/10] mpt3sas: Use the new MPI 2.6 32-bit Atomic Request Descriptors for SAS35 devices.

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> Support Atomic Request Descriptors for Ventura/SAS35 devices.
>
> Signed-off-by: Chaitra P B 
> Signed-off-by: Sathya Prakash 
> Signed-off-by: Suganath Prabu S 
> ---

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH 04/10] mpt3sas: Removing unused macro "MPT_DEVICE_TLR_ON"

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> Removing macro "MPT_DEVICE_TLR_ON" defined in header file as its unused
>
> Signed-off-by: Chaitra P B <chaitra.basa...@broadcom.com>
> Signed-off-by: Sathya Prakash <sathya.prak...@broadcom.com>
> Signed-off-by: Suganath Prabu S <suganath-prabu.subram...@broadcom.com>
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index 4221a4d..e923c91 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -375,7 +375,6 @@ struct MPT3SAS_TARGET {
>   * per device private data
>   */
>  #define MPT_DEVICE_FLAGS_INIT0x01
> -#define MPT_DEVICE_TLR_ON0x02
>  
>  #define MFG_PAGE10_HIDE_SSDS_MASK(0x0003)
>  #define MFG_PAGE10_HIDE_ALL_DISKS(0x00)

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH 02/10] mpt3sas: Fix for incorrect numbers for MSIX vectors enabled when non RDPQ card is enumerated first.

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> No. of MSIX vectors supported = min (Total no. of CPU cores,
> MSIX vectors supported by card)
>
> when RDPQ is disabled "max_msix_vectors" module parameter which was
> declared as global was set to '8' and hence if there are more than one card
> in system among which if RDPQ disabled card is enumerated first then only 8
> MSIX vectors was getting enabled for all the cards(including RDPQ enabled
> card,which can support more than 8 MSIX vectors).
>
> Used local variable instead of global variable ,if RDPQ is disabled this
> local variable is set to '8' else it is set to "max_msix_vectors" (by
> default this is set to -1, whose value can be set by user during driver
> load time).So now regardless of whether RDPQ disabled card is enumerated
> first or RDPQ enabled card is enumerated first , MSIX vectors enabled
> depends on the cards capability.
>
> Signed-off-by: Chaitra P B <chaitra.basa...@broadcom.com>
> Signed-off-by: Sathya Prakash <sathya.prak...@broadcom.com>
> Signed-off-by: Suganath Prabu S <suganath-prabu.subram...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas

Re: [PATCH 04/10] mpt3sas: Removing unused macro "MPT_DEVICE_TLR_ON"

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> Removing macro "MPT_DEVICE_TLR_ON" defined in header file as its unused
>
> Signed-off-by: Chaitra P B 
> Signed-off-by: Sathya Prakash 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index 4221a4d..e923c91 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -375,7 +375,6 @@ struct MPT3SAS_TARGET {
>   * per device private data
>   */
>  #define MPT_DEVICE_FLAGS_INIT0x01
> -#define MPT_DEVICE_TLR_ON0x02
>  
>  #define MFG_PAGE10_HIDE_SSDS_MASK(0x00000003)
>  #define MFG_PAGE10_HIDE_ALL_DISKS(0x00)

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH 02/10] mpt3sas: Fix for incorrect numbers for MSIX vectors enabled when non RDPQ card is enumerated first.

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> No. of MSIX vectors supported = min (Total no. of CPU cores,
> MSIX vectors supported by card)
>
> when RDPQ is disabled "max_msix_vectors" module parameter which was
> declared as global was set to '8' and hence if there are more than one card
> in system among which if RDPQ disabled card is enumerated first then only 8
> MSIX vectors was getting enabled for all the cards(including RDPQ enabled
> card,which can support more than 8 MSIX vectors).
>
> Used local variable instead of global variable ,if RDPQ is disabled this
> local variable is set to '8' else it is set to "max_msix_vectors" (by
> default this is set to -1, whose value can be set by user during driver
> load time).So now regardless of whether RDPQ disabled card is enumerated
> first or RDPQ enabled card is enumerated first , MSIX vectors enabled
> depends on the cards capability.
>
> Signed-off-by: Chaitra P B 
> Signed-off-by: Sathya Prakash 
> Signed-off-by: Suganath Prabu S 

Reviewed-by: Tomas Henzl 

Tomas

Re: [PATCH 08/10] mpt3sas: set EEDP-escape-flags for SAS35 devices.

[Tomas Henzl]

On 20.10.2016 14:20, Suganath Prabu S wrote:
> An UNMAP command on a PI formatted device will leave the Logical Block
> Application Tag and Logical Block Reference Tag as all F's (for those LBAs
> that are unmapped). To avoid IO errors if those LBAs are subsequently read
> before they are written with valid tag fields, the MPI SCSI IO requests
> need to set the EEDPFlags element EEDP Escape Mode field, Bits [7:6]
> appropriately. A value of 2 should be set to disable all PI checks if the
> Logical Block Application Tag is 0x for PI types 1 and 2.  A value
> of 3 should be set to disable all PI checks if the Logical Block
> Application Tag is 0x and the Logical Block Reference Tag is
> 0x for PI type 3.
>
> Signed-off-by: Chaitra P B <chaitra.basa...@broadcom.com>
> Signed-off-by: Sathya Prakash <sathya.prak...@broadcom.com>
> Signed-off-by: Suganath Prabu S <suganath-prabu.subram...@broadcom.com>

Reviewed-by: Tomas Henzl <the...@redhat.com>

Tomas