linux-kernel - RE: [PATCH v7 09/11] scsi: ufs: connect to RPMB subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5B8DA87D05A7694D9FA63FD143655C1B543C0457@hasmsx108.ger.corp.intel.com>
Date:   Wed, 22 Mar 2017 21:25:36 +0000
From:   "Winkler, Tomas" <tomas.winkler@...el.com>
To:     Christoph Hellwig <hch@....de>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        "Hunter, Adrian" <adrian.hunter@...el.com>,
        "James Bottomley" <James.Bottomley@...senPartnership.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        Vinayak Holikatti <vinholikatti@...il.com>,
        Andy Lutomirski <luto@...nel.org>,
        Arve Hj?nnev?g <arve@...roid.com>,
        "Michael Ryleev" <gmar@...gle.com>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        Yaniv Gardi <ygardi@...eaurora.org>,
        Avri Altman <avri.altman@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "Usyskin, Alexander" <alexander.usyskin@...el.com>
Subject: RE: [PATCH v7 09/11] scsi: ufs: connect to RPMB subsystem

> 
> On Mon, Nov 07, 2016 at 07:27:38PM +0000, Winkler, Tomas wrote:
> > I  value your opinion but I'm not responsible for inventing RPMB
> > and/or its  implementation storage devices (eMMC, UFC, NVMe), it's pretty
> much done deal out there in the wild.
> > I'm just trying to provide common API above it.

Somehow I've missed that answer, now I got back when search for comments before I'll post a new series.
 
> And the common API must go through the SCSI midlayer.  

I've actually tried to do  a midlayer, but I found it's too UFS specific, so there is no point to this abstraction.  
As not all needed data are accessible via scsi calls.  The solution I propose fits with what is done in eMMC (emmc specific  IOCTL).
There is already some code that breaks that layering in  ufshcd_set_dev_pwr_mode when talking to the special sdev_ufs.
Maybe I need more hint for the correct directions.

If it can't we won't
> support it, so please drop the UFS patches from the series.

If you have more constructive comments, I'll be glad to hear and address. 

Thanks
Tomas