RE: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw
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 command as well. If we use request->tag, how can we get tag for internal commands ? If driver allocate that, how can we make sure it will not conflict with the request->tag ? Regards, Viswas G > -Original Message- > From: John Garry > Sent: Monday, February 1, 2021 10:46 PM > To: Viswas G - I30667 ; j...@linux.ibm.com; > martin.peter...@oracle.com; akshat...@google.com; Ruksar Devadi - > I52327 ; 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 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, > > > > AFAIK, there is no such restrictions. Any queue can be used for > internal/external commands. > > > > ok, understood. > > BTW, to see even more performance improvement, it would be good to use > request->tag for ccb tag, rather that the LLDD manage this itself. I > mentioned this perviously elsewhere. Do you plan to make that change? > hisi_sas and megaraid sas are examples of drivers who do this. > > Thanks, > John > > > Regards, > > Viswas G > > > >> -Original Message- > >> From: John Garry > >> Sent: Monday, February 1, 2021 4:53 PM > >> To: Viswas G - I30667 ; j...@linux.ibm.com; > >> martin.peter...@oracle.com; akshat...@google.com; Ruksar Devadi - > >> I52327 ; 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 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 while testing this patch. > >> > >> Thanks for testing. > >> > >>> > >>> [ 246.724632] scsi host10: pm80xx > >>> [ 248.005258] sas: Enter sas_scsi_recover_host busy: 0 failed: 0 [ > >>> 248.168973] BUG: kernel NULL pointer dereference, address: > >>> 0110 [ 248.175926] #PF: supervisor read access in > >>> kernel mode [ 248.181065] #PF: error_code(0x) - not-present > >>> page [ 248.186196] PGD 0 P4D 0 [ 248.188736] Oops: [#1] SMP > >>> PTI [ 248.192230] CPU: 10 PID: 77 Comm: kworker/u26:2 Kdump: loaded > >> Tainted: G S OE 5.11.0-rc3 #2 > >>> [ 248.201614] Hardware name: Supermicro Super Server/X10DRi-LN4+, > >>> BIOS 3.1 06/08/2018 [ 248.209258] Workqueue: events_unbound > >>> async_run_entry_fn [ 248.214571] RIP: > >>> 0010:pm80xx_chip_sata_req+0x7f/0x5e0 [pm80xx] [ 248.220413] Code: > >>> c1 7c c1 e9 03 4d 8b ac 24 80 01 00 00 48 c7 44 24 14 00 00 00 00 89 > >>> 04 > >>> 24 31 c0 48 c7 84 24 88 00 00 00 00 00 00 00 f3 48 ab <48> 8b ba 10 > >>> 01 > >>> 00 00 e8 35 35 c6 ef c1 e8 10 89 44 24 04 0f b6 43 [ 248.239157] RSP: > >>> 0018:b98d834979f0 EFLAGS: 00010046 [ 248.244384] RAX: > >>> RBX: 9523c321c000 RCX: [ > >>> 248.251516] RDX: RSI: 952450720048 RDI: > >>> b98d83497a80 [ 248.258641] RBP: 9523c742 R08: > >>> 0100 R09: 0001 [ 248.265764] R10: > >>> 0001 R11: 9523c9e4 R12: 9523ca1c3600 [ > >>> 248.272887] R13: 9523c9e4 R14: b98d83497a04 R15: > >> 952450720048 [ 248.280013] FS: () > >> GS:9527afd0() knlGS: [ 248.288090] CS: > >> 0010 > >> DS: ES: CR0: 80050033 [ 248.293826] CR2: > >> 0110 CR3: 00029ac10001 CR4: 001706e0 [ > >> 248.300952] Call Trace: > >> > >> I think that the problem here is that ata_queued_cmd->scmd is NULL > >> for the ata internal command. > >> > >> Please try this fix: > >> > >> >8- > >> > >> @@ -4451,7 +4451,7 @@ static int pm80xx_chip_sata_req(struct > >> pm8001_hba_info *pm8001_ha, > >> struct scsi_cmnd *scmd = qc->scsicmd; > >> u32 tag = ccb->ccb_tag; > >> int ret; > >> - u32 q_index, blk_tag; > >> + u32 q_index = 0, blk_tag; > >> struct sata_start_req sata_cmd; > >> u32 hdr_tag, ncg_tag = 0; > >> u64 phys_addr, start_addr, end_addr; @@ -4463,8 +4463,10 @@ > >> static int pm80xx_chip_sata_req(struct pm8001_hba_info *pm8001_ha, > >> u32 opc = OP
RE: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw
Thanks John. We are planning to use request->tag for ccb tag. We will submit a
patch for that soon.
Regards,
Viswas G
> -Original Message-
> From: John Garry
> Sent: Monday, February 1, 2021 10:46 PM
> To: Viswas G - I30667 ; j...@linux.ibm.com;
> martin.peter...@oracle.com; akshat...@google.com; Ruksar Devadi -
> I52327 ; 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 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,
> >
> > AFAIK, there is no such restrictions. Any queue can be used for
> internal/external commands.
> >
>
> ok, understood.
>
> BTW, to see even more performance improvement, it would be good to use
> request->tag for ccb tag, rather that the LLDD manage this itself. I
> mentioned this perviously elsewhere. Do you plan to make that change?
> hisi_sas and megaraid sas are examples of drivers who do this.
>
> Thanks,
> John
>
> > Regards,
> > Viswas G
> >
> >> -Original Message-
> >> From: John Garry
> >> Sent: Monday, February 1, 2021 4:53 PM
> >> To: Viswas G - I30667 ; j...@linux.ibm.com;
> >> martin.peter...@oracle.com; akshat...@google.com; Ruksar Devadi -
> >> I52327 ; 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 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 while testing this patch.
> >>
> >> Thanks for testing.
> >>
> >>>
> >>> [ 246.724632] scsi host10: pm80xx
> >>> [ 248.005258] sas: Enter sas_scsi_recover_host busy: 0 failed: 0 [
> >>> 248.168973] BUG: kernel NULL pointer dereference, address:
> >>> 0110 [ 248.175926] #PF: supervisor read access in
> >>> kernel mode [ 248.181065] #PF: error_code(0x) - not-present
> >>> page [ 248.186196] PGD 0 P4D 0 [ 248.188736] Oops: [#1] SMP
> >>> PTI [ 248.192230] CPU: 10 PID: 77 Comm: kworker/u26:2 Kdump: loaded
> >> Tainted: G S OE 5.11.0-rc3 #2
> >>> [ 248.201614] Hardware name: Supermicro Super Server/X10DRi-LN4+,
> >>> BIOS 3.1 06/08/2018 [ 248.209258] Workqueue: events_unbound
> >>> async_run_entry_fn [ 248.214571] RIP:
> >>> 0010:pm80xx_chip_sata_req+0x7f/0x5e0 [pm80xx] [ 248.220413] Code:
> >>> c1 7c c1 e9 03 4d 8b ac 24 80 01 00 00 48 c7 44 24 14 00 00 00 00 89
> >>> 04
> >>> 24 31 c0 48 c7 84 24 88 00 00 00 00 00 00 00 f3 48 ab <48> 8b ba 10
> >>> 01
> >>> 00 00 e8 35 35 c6 ef c1 e8 10 89 44 24 04 0f b6 43 [ 248.239157] RSP:
> >>> 0018:b98d834979f0 EFLAGS: 00010046 [ 248.244384] RAX:
> >>> RBX: 9523c321c000 RCX: [
> >>> 248.251516] RDX: RSI: 952450720048 RDI:
> >>> b98d83497a80 [ 248.258641] RBP: 9523c742 R08:
> >>> 0100 R09: 0001 [ 248.265764] R10:
> >>> 0001 R11: 9523c9e4 R12: 9523ca1c3600 [
> >>> 248.272887] R13: 9523c9e4 R14: b98d83497a04 R15:
> >> 952450720048 [ 248.280013] FS: ()
> >> GS:9527afd0() knlGS: [ 248.288090] CS:
> >> 0010
> >> DS: ES: CR0: 80050033 [ 248.293826] CR2:
> >> 0110 CR3: 00029ac10001 CR4: 001706e0 [
> >> 248.300952] Call Trace:
> >>
> >> I think that the problem here is that ata_queued_cmd->scmd is NULL
> >> for the ata internal command.
> >>
> >> Please try this fix:
> >>
> >> >8-
> >>
> >> @@ -4451,7 +4451,7 @@ static int pm80xx_chip_sata_req(struct
> >> pm8001_hba_info *pm8001_ha,
> >> struct scsi_cmnd *scmd = qc->scsicmd;
> >> u32 tag = ccb->ccb_tag;
> >> int ret;
> >> - u32 q_index, blk_tag;
> >> + u32 q_index = 0, blk_tag;
> >> struct sata_start_req sata_cmd;
> >> u32 hdr_tag, ncg_tag = 0;
> >> u64 phys_addr, start_addr, end_addr; @@ -4463,8 +4463,10 @@
> >> static int pm80xx_chip_sata_req(struct pm8001_hba_info *pm8001_ha,
> >> u32 opc = OPC_INB_SATA_HOST_OPSTART;
> >> memset(&sata_cmd, 0, sizeof(sata_cmd));
> >>
> >> - blk_tag = blk_mq_unique_tag(scmd->request);
> >> - q_index = blk_mq_unique_tag_to_hwq(blk_tag);
> >> + if (scmd) {
> >> + blk_tag = blk_mq_unique_tag(scmd->request);
> >> + q_index = blk_
RE: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw
Hi John,
AFAIK, there is no such restrictions. Any queue can be used for
internal/external commands.
Regards,
Viswas G
> -Original Message-
> From: John Garry
> Sent: Monday, February 1, 2021 4:53 PM
> To: Viswas G - I30667 ; j...@linux.ibm.com;
> martin.peter...@oracle.com; akshat...@google.com; Ruksar Devadi -
> I52327 ; 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 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 while testing this patch.
>
> Thanks for testing.
>
> >
> > [ 246.724632] scsi host10: pm80xx
> > [ 248.005258] sas: Enter sas_scsi_recover_host busy: 0 failed: 0 [
> > 248.168973] BUG: kernel NULL pointer dereference, address:
> > 0110 [ 248.175926] #PF: supervisor read access in kernel
> > mode [ 248.181065] #PF: error_code(0x) - not-present page [
> > 248.186196] PGD 0 P4D 0 [ 248.188736] Oops: [#1] SMP PTI
> > [ 248.192230] CPU: 10 PID: 77 Comm: kworker/u26:2 Kdump: loaded
> Tainted: G S OE 5.11.0-rc3 #2
> > [ 248.201614] Hardware name: Supermicro Super Server/X10DRi-LN4+,
> > BIOS 3.1 06/08/2018 [ 248.209258] Workqueue: events_unbound
> > async_run_entry_fn [ 248.214571] RIP:
> > 0010:pm80xx_chip_sata_req+0x7f/0x5e0 [pm80xx] [ 248.220413] Code: c1
> > 7c c1 e9 03 4d 8b ac 24 80 01 00 00 48 c7 44 24 14 00 00 00 00 89 04
> > 24 31 c0 48 c7 84 24 88 00 00 00 00 00 00 00 f3 48 ab <48> 8b ba 10 01
> > 00 00 e8 35 35 c6 ef c1 e8 10 89 44 24 04 0f b6 43 [ 248.239157] RSP:
> > 0018:b98d834979f0 EFLAGS: 00010046 [ 248.244384] RAX:
> > RBX: 9523c321c000 RCX: [
> > 248.251516] RDX: RSI: 952450720048 RDI:
> > b98d83497a80 [ 248.258641] RBP: 9523c742 R08:
> > 0100 R09: 0001 [ 248.265764] R10:
> > 0001 R11: 9523c9e4 R12: 9523ca1c3600 [
> > 248.272887] R13: 9523c9e4 R14: b98d83497a04 R15:
> 952450720048 [ 248.280013] FS: ()
> GS:9527afd0() knlGS: [ 248.288090] CS: 0010
> DS: ES: CR0: 80050033 [ 248.293826] CR2:
> 0110 CR3: 00029ac10001 CR4: 001706e0 [
> 248.300952] Call Trace:
>
> I think that the problem here is that ata_queued_cmd->scmd is NULL for the
> ata internal command.
>
> Please try this fix:
>
> >8-
>
> @@ -4451,7 +4451,7 @@ static int pm80xx_chip_sata_req(struct
> pm8001_hba_info *pm8001_ha,
> struct scsi_cmnd *scmd = qc->scsicmd;
> u32 tag = ccb->ccb_tag;
> int ret;
> - u32 q_index, blk_tag;
> + u32 q_index = 0, blk_tag;
> struct sata_start_req sata_cmd;
> u32 hdr_tag, ncg_tag = 0;
> u64 phys_addr, start_addr, end_addr; @@ -4463,8 +4463,10 @@ static
> int pm80xx_chip_sata_req(struct pm8001_hba_info *pm8001_ha,
> u32 opc = OPC_INB_SATA_HOST_OPSTART;
> memset(&sata_cmd, 0, sizeof(sata_cmd));
>
> - blk_tag = blk_mq_unique_tag(scmd->request);
> - q_index = blk_mq_unique_tag_to_hwq(blk_tag);
> + if (scmd) {
> + blk_tag = blk_mq_unique_tag(scmd->request);
> + q_index = blk_mq_unique_tag_to_hwq(blk_tag);
> + }
> circularQ = &pm8001_ha->inbnd_q_tbl[q_index];
>
> 8<-
>
> You may need similar for other dispatch paths also - like smp - but I don't
> think that you will.
>
> BTW, do you know if there is actually a limitation on the HW that queue
> #0 is used for all "internal" IO (mpi), like phy control operation? Jack?
>
> Thanks,
> John
>
>
> > [ 248.303402] pm8001_task_exec.isra.9+0x2a4/0x460 [pm80xx] [
> > 248.308805] sas_ata_qc_issue+0x187/0x220 [libsas] [ 248.313607]
> > ata_qc_issue+0x107/0x1e0 [libata] [ 248.318069]
> > ata_exec_internal_sg+0x2c8/0x580 [libata] [ 248.323217]
> > ata_exec_internal+0x5f/0x90 [libata] [ 248.327931]
> > ata_dev_read_id+0x306/0x480 [libata] [ 248.332647]
> > ata_eh_recover+0x7ea/0x12a0 [libata] [ 248.337369] ?
> > vprintk_emit+0x114/0x220 [ 248.341208] ? sas_ata_sched_eh+0x60/0x60
> > [libsas] [ 248.346002] ? sas_ata_prereset+0x50/0x50 [libsas] [
> > 248.350795] ? printk+0x58/0x6f [ 248.353941] ?
> > sas_ata_sched_eh+0x60/0x60 [libsas] [ 248.358733] ?
> > sas_ata_prereset+0x50/0x50 [libsas] [ 248.363525]
> > ata_do_eh+0x40/0xb0 [libata] [ 248.367556]
> > ata_scsi_port_error_handler+0x354/0x770 [libata] [ 248.373318]
> > async_sas_ata_eh+0x44/0x7b [libsas] [ 248.377938]
> > async_run_entry_fn+0x39/0x160 [ 248.382040]
> > process_one_work+0x1cb/0x360 [ 248.386050
RE: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw
Thanks Johns. We could see a kernel crash while testing this patch. [ 246.724632] scsi host10: pm80xx [ 248.005258] sas: Enter sas_scsi_recover_host busy: 0 failed: 0 [ 248.168973] BUG: kernel NULL pointer dereference, address: 0110 [ 248.175926] #PF: supervisor read access in kernel mode [ 248.181065] #PF: error_code(0x) - not-present page [ 248.186196] PGD 0 P4D 0 [ 248.188736] Oops: [#1] SMP PTI [ 248.192230] CPU: 10 PID: 77 Comm: kworker/u26:2 Kdump: loaded Tainted: G S OE 5.11.0-rc3 #2 [ 248.201614] Hardware name: Supermicro Super Server/X10DRi-LN4+, BIOS 3.1 06/08/2018 [ 248.209258] Workqueue: events_unbound async_run_entry_fn [ 248.214571] RIP: 0010:pm80xx_chip_sata_req+0x7f/0x5e0 [pm80xx] [ 248.220413] Code: c1 7c c1 e9 03 4d 8b ac 24 80 01 00 00 48 c7 44 24 14 00 00 00 00 89 04 24 31 c0 48 c7 84 24 88 00 00 00 00 00 00 00 f3 48 ab <48> 8b ba 10 01 00 00 e8 35 35 c6 ef c1 e8 10 89 44 24 04 0f b6 43 [ 248.239157] RSP: 0018:b98d834979f0 EFLAGS: 00010046 [ 248.244384] RAX: RBX: 9523c321c000 RCX: [ 248.251516] RDX: RSI: 952450720048 RDI: b98d83497a80 [ 248.258641] RBP: 9523c742 R08: 0100 R09: 0001 [ 248.265764] R10: 0001 R11: 9523c9e4 R12: 9523ca1c3600 [ 248.272887] R13: 9523c9e4 R14: b98d83497a04 R15: 952450720048 [ 248.280013] FS: () GS:9527afd0() knlGS: [ 248.288090] CS: 0010 DS: ES: CR0: 80050033 [ 248.293826] CR2: 0110 CR3: 00029ac10001 CR4: 001706e0 [ 248.300952] Call Trace: [ 248.303402] pm8001_task_exec.isra.9+0x2a4/0x460 [pm80xx] [ 248.308805] sas_ata_qc_issue+0x187/0x220 [libsas] [ 248.313607] ata_qc_issue+0x107/0x1e0 [libata] [ 248.318069] ata_exec_internal_sg+0x2c8/0x580 [libata] [ 248.323217] ata_exec_internal+0x5f/0x90 [libata] [ 248.327931] ata_dev_read_id+0x306/0x480 [libata] [ 248.332647] ata_eh_recover+0x7ea/0x12a0 [libata] [ 248.337369] ? vprintk_emit+0x114/0x220 [ 248.341208] ? sas_ata_sched_eh+0x60/0x60 [libsas] [ 248.346002] ? sas_ata_prereset+0x50/0x50 [libsas] [ 248.350795] ? printk+0x58/0x6f [ 248.353941] ? sas_ata_sched_eh+0x60/0x60 [libsas] [ 248.358733] ? sas_ata_prereset+0x50/0x50 [libsas] [ 248.363525] ata_do_eh+0x40/0xb0 [libata] [ 248.367556] ata_scsi_port_error_handler+0x354/0x770 [libata] [ 248.373318] async_sas_ata_eh+0x44/0x7b [libsas] [ 248.377938] async_run_entry_fn+0x39/0x160 [ 248.382040] process_one_work+0x1cb/0x360 [ 248.386050] worker_thread+0x30/0x370 [ 248.389706] ? processe_work+0x360/0x360 [ 248.393884] kthread+0x116/0x130 [ 248.397116] ? kthread_park+0x80/0x80 [ 248.400773] ret_from_fork+0x22/0x30 [ 248.404355] Modules linked in: pm80xx(OE) libsas scsi_transport_sas xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun bridge stp llc rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass joydev crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ipmi_ssif iTCO_wdt iTCO_vendor_support mei_me rapl i2c_i801 intel_cstate mei acpi_ipmi lpc_ich intel_uncore pcspkr ipmi_si i2c_smbus ipmi_devintf ipmi_msghandler acpi_power_meter acpi_pad ioatdma ip_tables xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg ast drm_vram_helper drm_kms_helper syscopyarea igb sysfillrect sysimgblt fb_sys_fops drm_ttm_helper ttm ahci libahci dca drm crc32c_intel libata i2c_algo_bit wmi dm_mirror dm_region_hash dm_log dm_mod fuse [ 248.483431] CR2: 0110 [0.00] Linux version 5.11.0-rc3 (root@localhost.localdomain) (gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5), GNU ld version 2.30-79.el8) #2 SMP Mon Jan 25 23:56:12 IST 2021 [0.00] Command line: elfcorehr=0x4500 BOOT_IMAGE=(hd14,gpt2)/vmlinuz-5.11.0-rc3 ro resume=/dev/mapper/rhel-swap rhgb console=ttyS1,115200 loglevel=7 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug transparent_hugepage=never nokaslr novmcoredd hest_disable disable_cpu_apicid=0 > -Original Message- > From: John Garry > Sent: Tuesday, January 5, 2021 4:47 PM > To: j...@linux.ibm.com; martin.peter...@oracle.com; > akshat...@google.com; Viswas G - I30667 ; > Ruksar Devadi - I52327 ; > 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; 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
