All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avri Altman <Avri.Altman@wdc.com>
To: Bart Van Assche <bvanassche@acm.org>,
	"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
	"asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
	Zang Leigang <zangleigang@hisilicon.com>,
	Avi Shchislowski <Avi.Shchislowski@wdc.com>,
	Bean Huo <beanhuo@micron.com>,
	"cang@codeaurora.org" <cang@codeaurora.org>,
	"stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
	MOHAMMED RAFIQ KAMAL BASHA <md.rafiq@samsung.com>,
	Sang-yoon Oh <sangyoon.oh@samsung.com>,
	yongmyung lee <ymhungry.lee@samsung.com>,
	Jinyoung CHOI <j-young.choi@samsung.com>
Subject: RE: [RFC PATCH 00/13] scsi: ufs: Add HPB Support
Date: Sat, 16 May 2020 09:14:18 +0000	[thread overview]
Message-ID: <SN6PR04MB46408050B71E3A6225D6C495FCBA0@SN6PR04MB4640.namprd04.prod.outlook.com> (raw)
In-Reply-To: <d10b27f1-49ec-d092-b252-2bb8cdc4c66e@acm.org>

Hi Bart,

> 
> Hi Avri,
> 
> Thank you for having taken the time to publish your work. The way this
> series has been split into individual patches makes reviewing easy.
> Additionally, the cover letter and patch descriptions are very
> informative, insightful and well written. However, I'm concerned about a
> key aspect of the implementation, namely relying on a device handler to
> alter the meaning of a block layer request. My concern about this
> approach is that at most one device handler can be associated with a
> SCSI LLD. If in the future more functionality would be added to the UFS
> spec and if it would be desirable to implement that functionality as a
> new kernel module, it won't be possible to implement that functionality
> as a new device handler. So I think that not relying on the device
> handler infrastructure is more future proof because that removes the
> restrictions we have to deal with when using the device handler framework.
>  Thanks,
So should we keep perusing this direction, or leave it, and concentrate in Bean's RFC?
Or maybe come up with a 3rd way?

Thanks,
Avri

> 
> Bart.

  reply	other threads:[~2020-05-16  9:14 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-15 10:30 [RFC PATCH 00/13] scsi: ufs: Add HPB Support Avri Altman
2020-05-15 10:30 ` [RFC PATCH 01/13] scsi: ufs: Add HPB parameters Avri Altman
2020-05-15 10:30 ` [RFC PATCH 02/13] scsi: ufshpb: Init part I - Read HPB config Avri Altman
2020-05-15 15:33   ` Randy Dunlap
2020-05-15 19:33   ` kbuild test robot
2020-05-15 19:33   ` [RFC PATCH] scsi: ufshpb: ufshpb_luns_conf can be static kbuild test robot
2020-05-16  1:46   ` [RFC PATCH 02/13] scsi: ufshpb: Init part I - Read HPB config Bart Van Assche
2020-05-16  1:57   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 03/13] scsi: scsi_dh: Introduce scsi_dh_ufshpb Avri Altman
2020-05-16  1:48   ` Bart Van Assche
2020-05-16  2:16   ` kbuild test robot
2020-05-16  6:41   ` kbuild test robot
2020-05-15 10:30 ` [RFC PATCH 04/13] scsi: ufs: ufshpb: Init part II - Attach scsi device Avri Altman
2020-05-15 20:17   ` kbuild test robot
2020-05-15 20:17   ` [RFC PATCH] scsi: ufs: ufshpb: ufshpb_remove_lun() can be static kbuild test robot
2020-05-16  1:52   ` [RFC PATCH 04/13] scsi: ufs: ufshpb: Init part II - Attach scsi device Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 05/13] scsi: ufs: ufshpb: Disable HPB if no HPB-enabled luns Avri Altman
2020-05-16  2:02   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 06/13] scsi: scsi_dh: ufshpb: Prepare for L2P cache management Avri Altman
2020-05-16  2:13   ` Bart Van Assche
2020-05-16  3:01   ` kbuild test robot
2020-05-16  3:01   ` kbuild test robot
2020-05-15 10:30 ` [RFC PATCH 07/13] scsi: scsi_dh: ufshpb: Add ufshpb state machine Avri Altman
2020-05-16  2:44   ` Bart Van Assche
2020-05-16  5:56   ` kbuild test robot
2020-05-16  7:38   ` kbuild test robot
2020-05-15 10:30 ` [RFC PATCH 08/13] scsi: dh: ufshpb: Activate pinned regions Avri Altman
2020-05-15 10:30 ` [RFC PATCH 09/13] scsi: ufshpb: Add response API Avri Altman
2020-05-16  3:06   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 10/13] scsi: dh: ufshpb: Add ufshpb_set_params Avri Altman
2020-05-15 10:30 ` [RFC PATCH 11/13] scsi: Allow device handler set their own CDB Avri Altman
2020-05-16  3:19   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 12/13] scsi: dh: ufshpb: Add prep_fn handler Avri Altman
2020-05-16  3:40   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 13/13] scsi: scsi_dh: ufshpb: Add "Cold" subregions timer Avri Altman
2020-05-16  3:50 ` [RFC PATCH 00/13] scsi: ufs: Add HPB Support Bart Van Assche
2020-05-16  9:14   ` Avri Altman [this message]
2020-05-16 17:14     ` Bart Van Assche
     [not found]     ` <CGME20200516171420epcas2p108c570904c5117c3654d71e0a2842faa@epcms2p7>
2020-05-19 22:31       ` Another approach of UFSHPB yongmyung lee
2020-05-20 17:55         ` Christoph Hellwig
2020-05-20 21:19           ` Bart Van Assche
2020-05-22 16:35             ` Bart Van Assche
2020-05-22 16:49         ` Bart Van Assche
     [not found]         ` <CGME20200516171420epcas2p108c570904c5117c3654d71e0a2842faa@epcms2p4>
2020-05-25  5:40           ` Daejun Park
2020-05-25 14:56             ` Bart Van Assche
2020-05-26  6:15               ` Avri Altman
2020-05-26 17:03                 ` Bart Van Assche
     [not found]                 ` <CGME20200516171420epcas2p108c570904c5117c3654d71e0a2842faa@epcms2p3>
2020-05-27  9:11                   ` Daejun Park
2020-05-27 11:46                     ` Bean Huo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SN6PR04MB46408050B71E3A6225D6C495FCBA0@SN6PR04MB4640.namprd04.prod.outlook.com \
    --to=avri.altman@wdc.com \
    --cc=Avi.Shchislowski@wdc.com \
    --cc=alim.akhtar@samsung.com \
    --cc=asutoshd@codeaurora.org \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=cang@codeaurora.org \
    --cc=j-young.choi@samsung.com \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=md.rafiq@samsung.com \
    --cc=sangyoon.oh@samsung.com \
    --cc=stanley.chu@mediatek.com \
    --cc=ymhungry.lee@samsung.com \
    --cc=zangleigang@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.