Hi Christoph, Thank you for comments. My comments are inline below. Regards, Parshuram Thombare >-----Original Message----- >From: Christoph Hellwig <hch@xxxxxxxxxxxxx> >Sent: Tuesday, December 11, 2018 7:37 PM >To: Parshuram Raju Thombare <pthombar@xxxxxxxxxxx> >Cc: axboe@xxxxxxxxx; vinholikatti@xxxxxxxxx; jejb@xxxxxxxxxxxxxxxxxx; >martin.petersen@xxxxxxxxxx; mchehab+samsung@xxxxxxxxxx; >gregkh@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; akpm@linux- >foundation.org; nicolas.ferre@xxxxxxxxxxxxx; arnd@xxxxxxxx; linux- >kernel@xxxxxxxxxxxxxxx; linux-block@xxxxxxxxxxxxxxx; linux- >scsi@xxxxxxxxxxxxxxx; tj@xxxxxxxxxx; jbacik@xxxxxx; michaelcallahan@xxxxxx; >snitzer@xxxxxxxxxx; osandov@xxxxxx; keith.busch@xxxxxxxxx; >ming.lei@xxxxxxxxxx; shli@xxxxxx; dennisszhou@xxxxxxxxx; Alan Douglas ><adouglas@xxxxxxxxxxx>; Janek Kotas <jank@xxxxxxxxxxx>; Rafal Ciepiela ><rafalc@xxxxxxxxxxx> >Subject: Re: [PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD > >EXTERNAL MAIL > > >Patch 1 is missing in your series. > >But even without looking at it I think your design doesn't make a whole lot of >sense. If the encryption is implemented in the ufs driver you should not need >device mapper support for it, just ufs driver support and maybe a little block layer >glue. [PATCH 1/2] does nothing more than adding variable in 'struct bio'. Here is link of it. https://lkml.org/lkml/2018/12/11/193 One reason of using device mapper here is to use existing tools like 'dmsetup', otherwise some user space application is needed and may be some changes in block layer to pass the crypto information (crypto algorithm, key etc) till ufs driver. Another reason is supporting multiple UFS devices. I think, as you said UFS crypto support can be added by some change in ufs driver and block layer glue. But to support multiple UFS crypto devices having different crypto configs (crypto algorithms, key size etc), crypto context need to be saved per crypto device which may need some changes in block layer code.
