From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752554AbcI1J5a (ORCPT ); Wed, 28 Sep 2016 05:57:30 -0400 Received: from smtprelay.synopsys.com ([198.182.47.9]:46540 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751888AbcI1J5W (ORCPT ); Wed, 28 Sep 2016 05:57:22 -0400 Subject: Re: UFS API in the kernel To: , Kiwoong Kim References: <009f01d2185b$fcf71ef0$f6e55cd0$@samsung.com> <7275e74a9689721ea612fbc6eca555be@codeaurora.org> <99ac538d-5123-a58b-247d-160176f63a3d@synopsys.com> <875b9e3c-b413-97c2-3731-b8977e7618fd@synopsys.com> CC: "'Shaun Tancheff'" , "'Joao Pinto'" , , , , "Carlos Palminha" From: Joao Pinto Message-ID: <2481a900-429f-7fcf-8eb6-12a3f354d919@synopsys.com> Date: Wed, 28 Sep 2016 10:57:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <875b9e3c-b413-97c2-3731-b8977e7618fd@synopsys.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.107.19.69] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I was able to get the 7 patches to have the UFS IOCTL features from your repo. BTW, why weren't these features submitted to the kernel? I checked lots of tweaks that you have been making to the UFS... do you synchronize them periodically with the mainline? Thanks! On 9/28/2016 10:19 AM, Joao Pinto wrote: > > Hi again! > Could you also send me an example of how you are using the IOCTL from your user > app (send/receive data)? I already have my implemented but you use a different > mechanism (I have checked your structures in uapi/scsi/ufs/) and I have to port > it! Thanks! > > > On 9/28/2016 10:06 AM, Joao Pinto wrote: >> >> Hi Subhash, >> >> On 9/28/2016 12:05 AM, subhashj@codeaurora.org wrote: >>> Hi Joao, >>> >>> >>> On 2016-09-26 18:10, Kiwoong Kim wrote: >>>> Hi. >>>> >>>> If you want to declare some things for user interface, >>>> is it be better to put those thing include/uapi/linux/ than include/linux? >>>> >>>> Agreed with Mr. Pinto's opinion with respect to implementing additional ioctls. >>> >>> Yes, "scsi_host_template" allows the LLD's to export their ioctl callback and >>> then you can use the sg interface to issue UFS specific ioctls. We had >>> implemented similar ioctl for our use, here is the reference code: >>> https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/scsi/ufs/ufshcd.c?h=LA.HB.1.1.1.c2#n6791. >>> This was mainly done to export the UFS query request interface to user space. >>> Declarations where exported under include/uapi/scsi/ufs/ . If you want to build >>> upon this already existing functionality, i can post the formal patch on mailing >>> list. >> >> Yes, of course I have interest on building on top of what you have done already. >> Did yu submit this patch to the kernel already? Could you please send me the >> patch and kernel version to apply? >> >> Thanks, >> Joao >> >>> >>> Regards, >>> Subhash >>> >>> >>>> >>>> Regards. >>>> >>>>> -----Original Message----- >>>>> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi- >>>>> owner@vger.kernel.org] On Behalf Of Shaun Tancheff >>>>> Sent: Tuesday, September 27, 2016 4:23 AM >>>>> To: Joao Pinto >>>>> Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org >>>>> Subject: Re: UFS API in the kernel >>>>> >>>>> On Thu, Sep 22, 2016 at 10:21 AM, Joao Pinto >>>>> wrote: >>>>>> Hi! >>>>>> >>>>>> I am designing an application that has the goal to be an utility for >>>>>> Unipro and UFS testing purposes. This application is going to run on >>>>>> top of a recent Linux Kernel containing the new UFS stack (including the >>>>> new DWC drivers). >>>>>> >>>>>> I am considering doing the following: >>>>>> a) Create a new config item called CONFIG_UFS_CHARDEV which is going >>>>>> to create a char device responsible to make some IOCTL available for >>>>>> user-space applications >>>>>> b) Create a linux/ufs.h header file that contains data structures >>>>>> declarations that will be needed in user-space applications >>>>> >>>>> I am not very familiar with UFS devices, that said you should have an sgX >>>>> chardev being created already so you can handle SG_IO requests. >>>>> There also appear to be some sysfs entries being created. >>>>> >>>>> So between sg and sysfs you should be able to handle any user-space out of >>>>> band requests without resorting to making a new chardev. >>>>> >>>>> Adding more sysfs entries, if you need them, should be fine. >>>>> >>>>> You may find it easier to expand on the existing interfaces than to get >>>>> consensus on a new driver and ioctls. >>>>> >>>>> Hope this helps, >>>>> Shaun >>>>> >>>>>> Could you please advise me about what the correct approach should be >>>>>> to make it as standard as possible and usable in the future? >>>>>> >>>>>> Thank you very much for your help! >>>>>> >>>>>> regards, >>>>>> Joao >>>>>> -- >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" >>>>>> in the body of a message to majordomo@vger.kernel.org More majordomo >>>>>> info at >>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_ma >>>>>> jordomo-2Dinfo.html&d=DQICaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=Wg5NqlNlVTT7Ug >>>>>> l8V50qIHLe856QW0qfG3WVYGOrWzA&m=vJFB6pCywWtdvkgHz9Vc0jQz0xzeyZlr-7eCWY >>>>>> u88nM&s=yiQLPFpqmMrbqLZz1Jb3aNqOje2dRMLJHEzUDobwcXc&e= >>>>> >>>>> >>>>> >>>>> -- >>>>> Shaun Tancheff >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >>>>> the body of a message to majordomo@vger.kernel.org More majordomo info at >>>>> http://vger.kernel.org/majordomo-info.html >>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joao Pinto Subject: Re: UFS API in the kernel Date: Wed, 28 Sep 2016 10:57:16 +0100 Message-ID: <2481a900-429f-7fcf-8eb6-12a3f354d919@synopsys.com> References: <009f01d2185b$fcf71ef0$f6e55cd0$@samsung.com> <7275e74a9689721ea612fbc6eca555be@codeaurora.org> <99ac538d-5123-a58b-247d-160176f63a3d@synopsys.com> <875b9e3c-b413-97c2-3731-b8977e7618fd@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <875b9e3c-b413-97c2-3731-b8977e7618fd@synopsys.com> Sender: linux-kernel-owner@vger.kernel.org To: subhashj@codeaurora.org, Kiwoong Kim Cc: 'Shaun Tancheff' , 'Joao Pinto' , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-scsi-owner@vger.kernel.org, Carlos Palminha List-Id: linux-scsi@vger.kernel.org I was able to get the 7 patches to have the UFS IOCTL features from your repo. BTW, why weren't these features submitted to the kernel? I checked lots of tweaks that you have been making to the UFS... do you synchronize them periodically with the mainline? Thanks! On 9/28/2016 10:19 AM, Joao Pinto wrote: > > Hi again! > Could you also send me an example of how you are using the IOCTL from your user > app (send/receive data)? I already have my implemented but you use a different > mechanism (I have checked your structures in uapi/scsi/ufs/) and I have to port > it! Thanks! > > > On 9/28/2016 10:06 AM, Joao Pinto wrote: >> >> Hi Subhash, >> >> On 9/28/2016 12:05 AM, subhashj@codeaurora.org wrote: >>> Hi Joao, >>> >>> >>> On 2016-09-26 18:10, Kiwoong Kim wrote: >>>> Hi. >>>> >>>> If you want to declare some things for user interface, >>>> is it be better to put those thing include/uapi/linux/ than include/linux? >>>> >>>> Agreed with Mr. Pinto's opinion with respect to implementing additional ioctls. >>> >>> Yes, "scsi_host_template" allows the LLD's to export their ioctl callback and >>> then you can use the sg interface to issue UFS specific ioctls. We had >>> implemented similar ioctl for our use, here is the reference code: >>> https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/scsi/ufs/ufshcd.c?h=LA.HB.1.1.1.c2#n6791. >>> This was mainly done to export the UFS query request interface to user space. >>> Declarations where exported under include/uapi/scsi/ufs/ . If you want to build >>> upon this already existing functionality, i can post the formal patch on mailing >>> list. >> >> Yes, of course I have interest on building on top of what you have done already. >> Did yu submit this patch to the kernel already? Could you please send me the >> patch and kernel version to apply? >> >> Thanks, >> Joao >> >>> >>> Regards, >>> Subhash >>> >>> >>>> >>>> Regards. >>>> >>>>> -----Original Message----- >>>>> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi- >>>>> owner@vger.kernel.org] On Behalf Of Shaun Tancheff >>>>> Sent: Tuesday, September 27, 2016 4:23 AM >>>>> To: Joao Pinto >>>>> Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org >>>>> Subject: Re: UFS API in the kernel >>>>> >>>>> On Thu, Sep 22, 2016 at 10:21 AM, Joao Pinto >>>>> wrote: >>>>>> Hi! >>>>>> >>>>>> I am designing an application that has the goal to be an utility for >>>>>> Unipro and UFS testing purposes. This application is going to run on >>>>>> top of a recent Linux Kernel containing the new UFS stack (including the >>>>> new DWC drivers). >>>>>> >>>>>> I am considering doing the following: >>>>>> a) Create a new config item called CONFIG_UFS_CHARDEV which is going >>>>>> to create a char device responsible to make some IOCTL available for >>>>>> user-space applications >>>>>> b) Create a linux/ufs.h header file that contains data structures >>>>>> declarations that will be needed in user-space applications >>>>> >>>>> I am not very familiar with UFS devices, that said you should have an sgX >>>>> chardev being created already so you can handle SG_IO requests. >>>>> There also appear to be some sysfs entries being created. >>>>> >>>>> So between sg and sysfs you should be able to handle any user-space out of >>>>> band requests without resorting to making a new chardev. >>>>> >>>>> Adding more sysfs entries, if you need them, should be fine. >>>>> >>>>> You may find it easier to expand on the existing interfaces than to get >>>>> consensus on a new driver and ioctls. >>>>> >>>>> Hope this helps, >>>>> Shaun >>>>> >>>>>> Could you please advise me about what the correct approach should be >>>>>> to make it as standard as possible and usable in the future? >>>>>> >>>>>> Thank you very much for your help! >>>>>> >>>>>> regards, >>>>>> Joao >>>>>> -- >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" >>>>>> in the body of a message to majordomo@vger.kernel.org More majordomo >>>>>> info at >>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_ma >>>>>> jordomo-2Dinfo.html&d=DQICaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=Wg5NqlNlVTT7Ug >>>>>> l8V50qIHLe856QW0qfG3WVYGOrWzA&m=vJFB6pCywWtdvkgHz9Vc0jQz0xzeyZlr-7eCWY >>>>>> u88nM&s=yiQLPFpqmMrbqLZz1Jb3aNqOje2dRMLJHEzUDobwcXc&e= >>>>> >>>>> >>>>> >>>>> -- >>>>> Shaun Tancheff >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >>>>> the body of a message to majordomo@vger.kernel.org More majordomo info at >>>>> http://vger.kernel.org/majordomo-info.html >>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >