Message ID | 20221107131038.201724-1-beanhuo@iokpp.de |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2040674wru; Mon, 7 Nov 2022 05:12:47 -0800 (PST) X-Google-Smtp-Source: AMsMyM7BOUpqMc9+wgh46LDadpnJhnUfaeScNSlpTP5x7nh2q7dH9dzbMkWaEs+Iy3scxeftZUoj X-Received: by 2002:a17:906:6a18:b0:7ae:4a00:425f with SMTP id qw24-20020a1709066a1800b007ae4a00425fmr11360201ejc.581.1667826767669; Mon, 07 Nov 2022 05:12:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667826767; cv=none; d=google.com; s=arc-20160816; b=rqczj4YKiuExyroFOj8GF6iBqiqs7q+yr3YpndKBWU+K3y65aC2n/0yYamyTKr67uY ttY3Tq1j91JuxPaxBvVVkzKSeDbcAf7rQzG/LCbYRqtLPR6TRJ+5clx3Q26NiojA7k0e +jLpiH0uhBfak7makaDDAUIkeSEl9uvNfgER8R9AzJhCsfHCeeRUcsjsoZwhiWsToLfT nCe6P5TK7TYJX5pN/CNTMg7Rkd35NvbzXsobQKoYVSxnmdxITHenjtzH+Sd65fBpik9g 7XrSsjw7IRpwWgjDSH7E/a7/tEaabf79X5KVMfh91y6rZBClAFRbulKY5aMmMknECI0o pdwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=+rhn3V8+zDKpCdIBPe9SURIvaAZ23v/3ueIpZJEDWQ0=; b=WWhiBCC+DlYxXWkJ57vWuLziCLGc398fQhUCNxkKJTrxuEWYQoRVGLIA0gjarXyqle xIYuw58JTHITGdN6DY5NjYA91xkF2g9gnYmtZE7bcyCdRIlwyt2c7wDtBTHKK5oHE4ke KidCo0X4kEwaY1Tx9jlBSZmEvXd3ktxOshZFN0fksXPb+8Rc8/pTpxYV9B8DOsOW0aXn ZemnyLikcXHEoSNujW8DZ/P0+95l0eEhShM3+CywbYSXQY0O3qD1nFtKF8UTclsujZcd oMkO00xeN8h/brgayujmJPWIyzNcPlAL4RGbJuXUK4adE+PWz3cI3cNYyZF1Ca4ZnA52 iPwA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@iokpp.de header.s=strato-dkim-0002 header.b="g6dwblg/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id tz14-20020a170907c78e00b00780a882d337si6668150ejc.480.2022.11.07.05.12.21; Mon, 07 Nov 2022 05:12:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@iokpp.de header.s=strato-dkim-0002 header.b="g6dwblg/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232180AbiKGNLH (ORCPT <rfc822;hjfbswb@gmail.com> + 99 others); Mon, 7 Nov 2022 08:11:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232140AbiKGNLD (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 7 Nov 2022 08:11:03 -0500 Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [81.169.146.164]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB15F1C118; Mon, 7 Nov 2022 05:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1667826654; s=strato-dkim-0002; d=iokpp.de; h=Message-Id:Date:Subject:Cc:To:From:Cc:Date:From:Subject:Sender; bh=+rhn3V8+zDKpCdIBPe9SURIvaAZ23v/3ueIpZJEDWQ0=; b=g6dwblg/pDuVaigLWqElocSfGdhVaheY0cG1ITQ8y4QosjDFfaX1NhXPo9UFzO0eZ3 UwUNFupM+mLeeywVbst7wuVjX+piHoYp22OwcvdIZNszkpcYsey76+iJ294L7Tg3CfYH yJs0n/Gp0siCPkRvnsveshmza6L32rtnidpIyUBxtUKPo2LbaaA47N+95AwRn1ZqSxSI QJAO+os50OFPH/qy00eRhgNiN7HYnb85n3bhXfelS8wKBw4HZDT/EWMNdX8SnjM7PDLV QlZCFMAiYBq7SrZttfbLk8fk7RcY8GLA8NwJhCxNXmSfjWG1eoMqv6W78GZ7H8ZTtRmW ygxw== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":LmkFe0i9dN8c2t4QQyGBB/NDXvjDB6pBSedrgBzPc9DUyubU4DD1QLj68UeUr1+U1RvWtIeMr7Q/U8vM/+oObyVBycbphAC+CkWyag==" X-RZG-CLASS-ID: mo00 Received: from blinux.speedport.ip by smtp.strato.de (RZmta 48.2.1 AUTH) with ESMTPSA id z9cfbfyA7DArjG8 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 7 Nov 2022 14:10:53 +0100 (CET) From: Bean Huo <beanhuo@iokpp.de> To: alim.akhtar@samsung.com, avri.altman@wdc.com, jejb@linux.ibm.com, martin.petersen@oracle.com, stanley.chu@mediatek.com, beanhuo@micron.com, bvanassche@acm.org, tomas.winkler@intel.com, daejun7.park@samsung.com, quic_cang@quicinc.com, quic_nguyenb@quicinc.com, quic_xiaosenh@quicinc.com, quic_richardp@quicinc.com, quic_asutoshd@quicinc.com, hare@suse.de Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, Bean Huo <beanhuo@iokpp.de> Subject: [RFC PATCH v1 0/2] UFS Advanced RPMB Date: Mon, 7 Nov 2022 14:10:36 +0100 Message-Id: <20221107131038.201724-1-beanhuo@iokpp.de> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748843120717948376?= X-GMAIL-MSGID: =?utf-8?q?1748843120717948376?= |
Series |
UFS Advanced RPMB
|
|
Message
Bean Huo
Nov. 7, 2022, 1:10 p.m. UTC
In UFS 4.0, it introduced advanced RPMB, which can significantly improve RPMB's command performance, enhancing its atomic operation. We don't know which implementation will please everyone, mark this advanced RPMB patch as RFC. Any suggestions to make the patch a master patch are welcome. Based on suggestions and feedback from Hannes Reinecke and Bart, we can use job_bsg->request and job_bsg->reply to pass EHS packets without changing the BSG V4 structure and BSG core. So we push RFC patch just to start Advanced RPMB mainlining Bean Huo (2): ufs: core: Advanced RPMB detection ufs: core: Add advanced RPMB support in ufs_bsg drivers/ufs/core/ufs_bsg.c | 115 +++++++++++++--------- drivers/ufs/core/ufshcd.c | 161 ++++++++++++++++++++++++------- include/uapi/scsi/scsi_bsg_ufs.h | 30 +++++- include/ufs/ufs.h | 3 + include/ufs/ufshcd.h | 5 + 5 files changed, 233 insertions(+), 81 deletions(-)
Comments
Hi, > In UFS 4.0, it introduced advanced RPMB, which can significantly improve > RPMB's command performance, enhancing its atomic operation. We don't > know which implementation will please everyone, mark this advanced RPMB > patch as RFC. Any suggestions to make the patch a master patch are welcome. > > Based on suggestions and feedback from Hannes Reinecke and Bart, we can > use job_bsg->request and job_bsg->reply to pass EHS packets without changing > the BSG V4 structure and BSG core. Can you share the reference to this mail thread, or was it a privet discussion? Thanks, Avri >So we push RFC patch just to start > Advanced RPMB mainlining > > Bean Huo (2): > ufs: core: Advanced RPMB detection > ufs: core: Add advanced RPMB support in ufs_bsg > > drivers/ufs/core/ufs_bsg.c | 115 +++++++++++++--------- > drivers/ufs/core/ufshcd.c | 161 ++++++++++++++++++++++++------- > include/uapi/scsi/scsi_bsg_ufs.h | 30 +++++- > include/ufs/ufs.h | 3 + > include/ufs/ufshcd.h | 5 + > 5 files changed, 233 insertions(+), 81 deletions(-) > > -- > 2.25.1
On Tue, 2022-11-08 at 12:37 +0000, Avri Altman wrote: > Hi, > > > In UFS 4.0, it introduced advanced RPMB, which can significantly > > improve > > RPMB's command performance, enhancing its atomic operation. We > > don't > > know which implementation will please everyone, mark this advanced > > RPMB > > patch as RFC. Any suggestions to make the patch a master patch are > > welcome. > > Based on suggestions and feedback from Hannes Reinecke and Bart, we > > can > > use job_bsg->request and job_bsg->reply to pass EHS packets without > > changing > > the BSG V4 structure and BSG core. > > Can you share the reference to this mail thread, or was it a privet > discussion? > > > > Thanks, > > Avri Avri, Yes, this is a private discussion during this year's Storage Summit wit h Hannes Reinecke on the first two proposals below, and a private discussion with Bart on the following three proposals 1. Use current BSG v4, and transmit EHS in sense_buffer, which is rejected. 2. The optional suggestion is to use ufs_bsg, which is the patch. 3. New RPMB framework, but we should enable UFS/eMMC RPMB driver as well in ufs/emmc core, also, the command will be passed to kernel over ioctl(). interested in this one, But Bart suggested using io_uing framework. Since RPMB operation is atomic required, we found it is not safe to use io_uring now, this need passthorugh support SCSI layer as well. Kind regards, Bean
> In UFS 4.0, it introduced advanced RPMB, which can significantly improve > RPMB's command performance, enhancing its atomic operation. We don't > know which implementation will please everyone, mark this advanced RPMB > patch as RFC. Any suggestions to make the patch a master patch are welcome. > > Based on suggestions and feedback from Hannes Reinecke and Bart, we can > use job_bsg->request and job_bsg->reply to pass EHS packets without changing > the BSG V4 structure and BSG core. So we push RFC patch just to start > Advanced RPMB mainlining I concur with this approach. The current limitations that the new spec imposes, e.g. putting confidential data in a construct that lives in the ufs-driver, practically gives no other alternative but ufs-bsg. If no one else object, maybe you can leave out the rfc from the next version. Thanks, Avri > > Bean Huo (2): > ufs: core: Advanced RPMB detection > ufs: core: Add advanced RPMB support in ufs_bsg > > drivers/ufs/core/ufs_bsg.c | 115 +++++++++++++--------- > drivers/ufs/core/ufshcd.c | 161 ++++++++++++++++++++++++------- > include/uapi/scsi/scsi_bsg_ufs.h | 30 +++++- > include/ufs/ufs.h | 3 + > include/ufs/ufshcd.h | 5 + > 5 files changed, 233 insertions(+), 81 deletions(-) > > -- > 2.25.1
Avri, Thanks for your suggetions and review On Wed, 2022-11-09 at 08:18 +0000, Avri Altman wrote: > > In UFS 4.0, it introduced advanced RPMB, which can significantly > > improve > > RPMB's command performance, enhancing its atomic operation. We > > don't > > know which implementation will please everyone, mark this advanced > > RPMB > > patch as RFC. Any suggestions to make the patch a master patch are > > welcome. > > Based on suggestions and feedback from Hannes Reinecke and Bart, we > > can > > use job_bsg->request and job_bsg->reply to pass EHS packets without > > changing > > the BSG V4 structure and BSG core. So we push RFC patch just to > > start > > Advanced RPMB mainlining > > I concur with this approach. > > The current limitations that the new spec imposes, > > e.g. putting confidential data in a construct that lives in the ufs- > driver, > > practically gives no other alternative but ufs-bsg. > > > > If no one else object, maybe you can leave out the rfc from the next > version. > > I will prepare next version, and address your all questions in the next version. thanks. Kind regards, Bean