Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-02-16 Thread Hannes Reinecke
On 2/15/21 6:31 PM, viswa...@microchip.com wrote: Hi John, We could test this patch and it works fine. Regarding the usage of request->tag, We have some challenges there. Pm80xx driver need tag for internal command as well. Tag is controller wide and we need to assign unique tag for internal

Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-02-15 Thread John Garry
2327 ; ra...@google.com; bjashn...@google.com; vishakh...@google.com; jinpu.w...@cloud.ionos.com; Ashokkumar N - X53535 Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; h...@suse.de; kashyap.de...@broadcom.com; ming@redhat.com Subject: Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues f

RE: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-02-15 Thread Viswas.G
.de; > kashyap.de...@broadcom.com; ming....@redhat.com > Subject: Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx > hw > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 01/02/2021 17:08, viswa...@microchip.com w

RE: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-02-01 Thread Viswas.G
m; ming....@redhat.com > Subject: Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx > hw > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 01/02/2021 17:08, viswa...@microchip.com wrote: > > Hi John, >

Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-02-01 Thread John Garry
.de...@broadcom.com; ming@redhat.com Subject: Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On 31/01/2021 07:19, viswa...@microchip.com wrote: Thanks Johns. We could see a kernel crash wh

RE: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-02-01 Thread Viswas.G
om; ming....@redhat.com > Subject: Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx > hw > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 31/01/2021 07:19, viswa...@microchip.com wrote: > > Thanks Johns.

Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-02-01 Thread John Garry
.@google.com; jinpu.w...@cloud.ionos.com; Ashokkumar N - X53535 Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; h...@suse.de; kashyap.de...@broadcom.com; ming....@redhat.com; John Garry Subject: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw EXTERNAL EMAIL: Do not click l

RE: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-01-30 Thread Viswas.G
use.de; > kashyap.de...@broadcom.com; ming@redhat.com; John Garry > > Subject: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > In commit 05c6c029a44d (&qu

Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-01-11 Thread John Garry
On 11/01/2021 11:57, Jinpu Wang wrote: Hi John, On Tue, Jan 5, 2021 at 12:21 PM John Garry wrote: In commit 05c6c029a44d ("scsi: pm80xx: Increase number of supported queues"), support for 80xx chip was improved by enabling multiple HW queues. In this, like other SCSI MQ HBA drivers, the HW

Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-01-11 Thread Jinpu Wang
Hi John, On Tue, Jan 5, 2021 at 12:21 PM John Garry wrote: > > In commit 05c6c029a44d ("scsi: pm80xx: Increase number of supported > queues"), support for 80xx chip was improved by enabling multiple HW > queues. > > In this, like other SCSI MQ HBA drivers, the HW queues were not exposed > to

[RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw

2021-01-05 Thread John Garry
In commit 05c6c029a44d ("scsi: pm80xx: Increase number of supported queues"), support for 80xx chip was improved by enabling multiple HW queues. In this, like other SCSI MQ HBA drivers, the HW queues were not exposed to upper layer, and instead the driver managed the queues internally. However,