RE: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Winkler, Tomas]

> 
> On 03/11/2016 02:43 AM, Martin K. Petersen wrote:
> >> "Arnd" == Arnd Bergmann  writes:
> >
> > Arnd> Looking through what other drivers do, I've found a couple of
> > Arnd> patterns now. n particular, most use the SG_IO ioctl to pass down
> > Arnd> commands from user space into a device specific command
> > Arnd> queue. Have you looked at that interface in the past to see if it
> > Arnd> would fit your use case?
> >
> > Arnd> There is also a 'bsg' API that some drivers implement, which I
> > Arnd> think would be another alternative.
> >
> > Arnd> Could any of the SCSI experts comment on what they expect a driver
> > Arnd> to use out of those three alternatives (if any):
> >
> > My preference is that if you want to expose any information that a user
> > or admin would care about, put it in sysfs where it is easily accessible
> > and can be scripted.
> >
> > For things that need to directly send commands to the hardware (to
> > configure vendor specific settings or inspect parameters for development
> > purposes) use the sg or bsg interfaces like we do for both ATA and
> > SCSI. bsg is newer and supports more features like bidirectional
> > commands. But for this particular use case I don't think it offers any
> > particular advantages over SG_IO. Both interfaces take the same
> > descriptors so it really doesn't matter much.
> >
> > See:
> >
> > http://sg.danny.cz/sg/
> >
> And indeed I would expose this 'special' UFS RPMB as a 'generic'
> SCSI device and add the required fields in sysfs, much like Greg KH
> suggested.
> Plus adding a 'bsg' interface for sending 'raw' UFS commands sounds
> much more appealing; that's what we do for SAS and FC, too.
> 
> But then, none of the above can be done if there is no hardware
> available. At the same time, you wouldn't be able to test any
> proposed fixes to the original ioctl patch.
> So I guess you'll have to retract this patch or get hold of the
> hardware to actually _test_ something there.
> 
> Or send me some, I'll be happy to help out here :-)
> 

I will submit proposal or new RPMB layer for both UFS and EMMC 
It also sports IOCTL interface, similar and replacing to mmc_ioc_cmd which is 
also used to access RPMB partition on emmc.
Blocks  of 512 bytes has to be transferred back and force so sysfs API is not 
good enough.  RPMB partition is not suitable to be accessed via block layer.  
I've tried going via SICSI generic layers, it is a bit awkward as the protocol 
is very UFS specific.  
Currently I have working solution for both EMMC and UFS2.0.

Thanks
Tomas 

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Hannes Reinecke]

On 03/11/2016 02:43 AM, Martin K. Petersen wrote:
>> "Arnd" == Arnd Bergmann  writes:
> 
> Arnd> Looking through what other drivers do, I've found a couple of
> Arnd> patterns now. n particular, most use the SG_IO ioctl to pass down
> Arnd> commands from user space into a device specific command
> Arnd> queue. Have you looked at that interface in the past to see if it
> Arnd> would fit your use case?
> 
> Arnd> There is also a 'bsg' API that some drivers implement, which I
> Arnd> think would be another alternative.
> 
> Arnd> Could any of the SCSI experts comment on what they expect a driver
> Arnd> to use out of those three alternatives (if any):
> 
> My preference is that if you want to expose any information that a user
> or admin would care about, put it in sysfs where it is easily accessible
> and can be scripted.
> 
> For things that need to directly send commands to the hardware (to
> configure vendor specific settings or inspect parameters for development
> purposes) use the sg or bsg interfaces like we do for both ATA and
> SCSI. bsg is newer and supports more features like bidirectional
> commands. But for this particular use case I don't think it offers any
> particular advantages over SG_IO. Both interfaces take the same
> descriptors so it really doesn't matter much.
> 
> See:
> 
>   http://sg.danny.cz/sg/
> 
And indeed I would expose this 'special' UFS RPMB as a 'generic'
SCSI device and add the required fields in sysfs, much like Greg KH
suggested.
Plus adding a 'bsg' interface for sending 'raw' UFS commands sounds
much more appealing; that's what we do for SAS and FC, too.

But then, none of the above can be done if there is no hardware
available. At the same time, you wouldn't be able to test any
proposed fixes to the original ioctl patch.
So I guess you'll have to retract this patch or get hold of the
hardware to actually _test_ something there.

Or send me some, I'll be happy to help out here :-)

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Martin K. Petersen]

> "Arnd" == Arnd Bergmann  writes:

Arnd> Looking through what other drivers do, I've found a couple of
Arnd> patterns now. n particular, most use the SG_IO ioctl to pass down
Arnd> commands from user space into a device specific command
Arnd> queue. Have you looked at that interface in the past to see if it
Arnd> would fit your use case?

Arnd> There is also a 'bsg' API that some drivers implement, which I
Arnd> think would be another alternative.

Arnd> Could any of the SCSI experts comment on what they expect a driver
Arnd> to use out of those three alternatives (if any):

My preference is that if you want to expose any information that a user
or admin would care about, put it in sysfs where it is easily accessible
and can be scripted.

For things that need to directly send commands to the hardware (to
configure vendor specific settings or inspect parameters for development
purposes) use the sg or bsg interfaces like we do for both ATA and
SCSI. bsg is newer and supports more features like bidirectional
commands. But for this particular use case I don't think it offers any
particular advantages over SG_IO. Both interfaces take the same
descriptors so it really doesn't matter much.

See:

http://sg.danny.cz/sg/

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Arnd Bergmann]

On Thursday 10 March 2016, Arnd Bergmann wrote:
> On Wednesday 09 March 2016, yga...@codeaurora.org wrote:
> > Any userspace application can be a tool.
> > We already implemented and used a user space application, that sent
> > queries to the UFS devices in order to get information and descriptors.
> > Not only ioctl interface is a useful way to interact with the device,
> > we used it, and found it very helpful in varies cases.
> > hence, this patch.
> > This patch has been already addressed all comments of Arnd Bergman from 5
> > months ago, and now, re-uploaded again.
> 
> Do you have a pointer to that review? It's been a long while, so I
> have completely forgotten what issues I raised and how it got resolved.

I got your link in private message and read up on it again now.

To clarify: I commented on the formal API definition, and you indeed addressed
all my concerns, so this is now an ioctl command that follows our usual
calling conventions.

However, this is orthogonal to the question of whether it is a good idea
to have this interface implemented as an ioctl as asked by Greg, and who
is actually using it. 

I'm lacking the detailed subsystem knowledge to answer this, but
I note that other block drivers have similar passthrough interfaces.

Looking through what other drivers do, I've found a couple of patterns
now. n particular, most use the SG_IO ioctl to pass down commands
from user space into a device specific command queue. Have you looked
at that interface in the past to see if it would fit your use case?

There is also a 'bsg' API that some drivers implement, which I think
would be another alternative.

Could any of the SCSI experts comment on what they expect a driver
to use out of those three alternatives (if any): 

* private ioctl
* bsg
* sg_io

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Greg KH]

On Thu, Mar 10, 2016 at 06:48:54PM -, yga...@codeaurora.org wrote:
> > On Thu, Mar 10, 2016 at 04:29:55PM -, yga...@codeaurora.org wrote:
> >> > On Thu, Mar 10, 2016 at 03:52:54PM -, yga...@codeaurora.org wrote:
> >> >> > On Wed, Mar 09, 2016 at 08:52:59PM -, yga...@codeaurora.org
> >> wrote:
> >> >> >> > On Wed, Mar 09, 2016 at 07:09:49PM -, yga...@codeaurora.org
> >> >> wrote:
> >> >> >> >> > On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
> >> >> >> >> >> This patch exposes the ioctl interface for UFS driver via
> >> SCSI
> >> >> >> device
> >> >> >> >> >> ioctl interface. As of now UFS driver would provide the
> >> ioctl
> >> >> for
> >> >> >> >> query
> >> >> >> >> >> interface to connected UFS device.
> >> >> >> >> >>
> >> >> >> >> >> Reviewed-by: Subhash Jadavani 
> >> >> >> >> >> Signed-off-by: Dolev Raviv 
> >> >> >> >> >> Signed-off-by: Gilad Broner 
> >> >> >> >> >> Signed-off-by: Yaniv Gardi 
> >> >> >> >> >
> >> >> >> >> > What tool is going to use this ioctl?  Why does userspcae
> >> want
> >> >> to
> >> >> >> do
> >> >> >> >> > something "special" with UFS devices?  Shouldn't they just be
> >> >> >> treated
> >> >> >> >> > like any other normal block device?
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> Any userspace application can be a tool.
> >> >> >> >> We already implemented and used a user space application, that
> >> >> sent
> >> >> >> >> queries to the UFS devices in order to get information and
> >> >> >> descriptors.
> >> >> >> >
> >> >> >> > But do you want to do with that information?  Why does userspace
> >> >> care?
> >> >> >> >
> >> >> >>
> >> >> >> i don't really understand the subtext of your question -
> >> >> >> as ANY ioctl cb, we decided to implement the ioctl callback of
> >> this
> >> >> scsi
> >> >> >> device in order to get information like UNIT DESC, DEVICE DESC,
> >> >> FLAGs,
> >> >> >> ATTRIBUTES.
> >> >> >> When dealing with UFS devices, one should be able to read the
> >> >> >> characteristics of the device. why ? well, why not ?
> >> >> >
> >> >> > Why aren't those characteristics just exported as sysfs attributes
> >> >> under
> >> >> > control by the UFS controller driver?  Why do you need/want an
> >> ioctl
> >> >> for
> >> >> > this?
> >> >> >
> >> >>
> >> >> Hi greg k-h,
> >> >>
> >> >> in our code, we used the IOCTL during runtime, in order to determine
> >> >> some
> >> >> information about the RPMB well known lun.
> >> >> with the rpmb lun ID we could then go to /dev/sgX and issue
> >> >> UFS_IOCTL_QUERY to this lun and get the data -
> >> >> reading the QUERY_DESC_IDN_GEOMETRY descriptor and reading the
> >> >> QUERY_DESC_IDN_UNIT descriptor.
> >> >>
> >> >> this was crucial to the work we do in RPMB.
> >> >
> >> > What is RPMB?
> >> >
> >> > And again, why not just use sysfs attributes on your host controller
> >> > device?  Why does this have to be a custom ioctl?
> >> >
> >> > greg k-h
> >> >
> >>
> >> RPMB is spcial Logical Unit in the UFS device. you can read about it in
> >> the UFS spec. Greg, you are insisting on sysfs, but i can't implement it
> >> now, as i don't have the Hardware anymore, or the time.
> >
> > If you don't have the hardware, how are you testing this patch?
> 
> This patch is already tested and verified, and also was much helpful
> during development.
> Also, this patch is a few months old and was tested when previous version
> were uploaded.
> Currently HW is not available.
> >
> > And if you don't have the hardware I guess you don't need this change :)
> >
> >> This is a tested and verified code that was accepted and reviewed
> >> already,
> >> so i'm not sure what is wrong with this solution, not to say, it's
> >> already
> >> implemented, tested and verified.
> >> hope you are help us push it.
> >
> > That's a horrible reason to merge a patch that someone else is going to
> > have to support for 20+ years with an api that doesn't make much sense.
> >
> > If you don't have the hardware, then this isn't needed.  But if you do,
> 
> Even if currently HW is not available it doesn't mean this is not needed
> in the future again.

Great, if in the future, you need this again, please resubmit it.
Adding code to the kernel for no real user is a maintaince burden on
others.  Please don't do that.  Especially for an API that is now
required to be supported for forever.

> > then please look into using sysfs for this, as I think that should be
> > the correct interface here, again, not some random ioctl.
> >
> 
> Why sysfs makes more sense than this one ?

Why doesn't it?  Why would an ioctl make sense to get simple attributes
from a host controller?  Why not use the interface that makes it trivial
to use from userspace that other drivers already use in this type of
situation.

In other words, why do you have to have this ioctl?  What requires this
to be the way the API works?

But again, as you don't need 

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[ygardi]

> On Thu, Mar 10, 2016 at 04:29:55PM -, yga...@codeaurora.org wrote:
>> > On Thu, Mar 10, 2016 at 03:52:54PM -, yga...@codeaurora.org wrote:
>> >> > On Wed, Mar 09, 2016 at 08:52:59PM -, yga...@codeaurora.org
>> wrote:
>> >> >> > On Wed, Mar 09, 2016 at 07:09:49PM -, yga...@codeaurora.org
>> >> wrote:
>> >> >> >> > On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
>> >> >> >> >> This patch exposes the ioctl interface for UFS driver via
>> SCSI
>> >> >> device
>> >> >> >> >> ioctl interface. As of now UFS driver would provide the
>> ioctl
>> >> for
>> >> >> >> query
>> >> >> >> >> interface to connected UFS device.
>> >> >> >> >>
>> >> >> >> >> Reviewed-by: Subhash Jadavani 
>> >> >> >> >> Signed-off-by: Dolev Raviv 
>> >> >> >> >> Signed-off-by: Gilad Broner 
>> >> >> >> >> Signed-off-by: Yaniv Gardi 
>> >> >> >> >
>> >> >> >> > What tool is going to use this ioctl?  Why does userspcae
>> want
>> >> to
>> >> >> do
>> >> >> >> > something "special" with UFS devices?  Shouldn't they just be
>> >> >> treated
>> >> >> >> > like any other normal block device?
>> >> >> >> >
>> >> >> >>
>> >> >> >> Any userspace application can be a tool.
>> >> >> >> We already implemented and used a user space application, that
>> >> sent
>> >> >> >> queries to the UFS devices in order to get information and
>> >> >> descriptors.
>> >> >> >
>> >> >> > But do you want to do with that information?  Why does userspace
>> >> care?
>> >> >> >
>> >> >>
>> >> >> i don't really understand the subtext of your question -
>> >> >> as ANY ioctl cb, we decided to implement the ioctl callback of
>> this
>> >> scsi
>> >> >> device in order to get information like UNIT DESC, DEVICE DESC,
>> >> FLAGs,
>> >> >> ATTRIBUTES.
>> >> >> When dealing with UFS devices, one should be able to read the
>> >> >> characteristics of the device. why ? well, why not ?
>> >> >
>> >> > Why aren't those characteristics just exported as sysfs attributes
>> >> under
>> >> > control by the UFS controller driver?  Why do you need/want an
>> ioctl
>> >> for
>> >> > this?
>> >> >
>> >>
>> >> Hi greg k-h,
>> >>
>> >> in our code, we used the IOCTL during runtime, in order to determine
>> >> some
>> >> information about the RPMB well known lun.
>> >> with the rpmb lun ID we could then go to /dev/sgX and issue
>> >> UFS_IOCTL_QUERY to this lun and get the data -
>> >> reading the QUERY_DESC_IDN_GEOMETRY descriptor and reading the
>> >> QUERY_DESC_IDN_UNIT descriptor.
>> >>
>> >> this was crucial to the work we do in RPMB.
>> >
>> > What is RPMB?
>> >
>> > And again, why not just use sysfs attributes on your host controller
>> > device?  Why does this have to be a custom ioctl?
>> >
>> > greg k-h
>> >
>>
>> RPMB is spcial Logical Unit in the UFS device. you can read about it in
>> the UFS spec. Greg, you are insisting on sysfs, but i can't implement it
>> now, as i don't have the Hardware anymore, or the time.
>
> If you don't have the hardware, how are you testing this patch?

This patch is already tested and verified, and also was much helpful
during development.
Also, this patch is a few months old and was tested when previous version
were uploaded.
Currently HW is not available.
>
> And if you don't have the hardware I guess you don't need this change :)
>
>> This is a tested and verified code that was accepted and reviewed
>> already,
>> so i'm not sure what is wrong with this solution, not to say, it's
>> already
>> implemented, tested and verified.
>> hope you are help us push it.
>
> That's a horrible reason to merge a patch that someone else is going to
> have to support for 20+ years with an api that doesn't make much sense.
>
> If you don't have the hardware, then this isn't needed.  But if you do,

Even if currently HW is not available it doesn't mean this is not needed
in the future again.

> then please look into using sysfs for this, as I think that should be
> the correct interface here, again, not some random ioctl.
>

Why sysfs makes more sense than this one ?


> greg k-h
>


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Arnd Bergmann]

On Wednesday 09 March 2016, yga...@codeaurora.org wrote:
> Any userspace application can be a tool.
> We already implemented and used a user space application, that sent
> queries to the UFS devices in order to get information and descriptors.
> Not only ioctl interface is a useful way to interact with the device,
> we used it, and found it very helpful in varies cases.
> hence, this patch.
> This patch has been already addressed all comments of Arnd Bergman from 5
> months ago, and now, re-uploaded again.

Do you have a pointer to that review? It's been a long while, so I
have completely forgotten what issues I raised and how it got resolved.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Greg KH]

On Thu, Mar 10, 2016 at 04:29:55PM -, yga...@codeaurora.org wrote:
> > On Thu, Mar 10, 2016 at 03:52:54PM -, yga...@codeaurora.org wrote:
> >> > On Wed, Mar 09, 2016 at 08:52:59PM -, yga...@codeaurora.org wrote:
> >> >> > On Wed, Mar 09, 2016 at 07:09:49PM -, yga...@codeaurora.org
> >> wrote:
> >> >> >> > On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
> >> >> >> >> This patch exposes the ioctl interface for UFS driver via SCSI
> >> >> device
> >> >> >> >> ioctl interface. As of now UFS driver would provide the ioctl
> >> for
> >> >> >> query
> >> >> >> >> interface to connected UFS device.
> >> >> >> >>
> >> >> >> >> Reviewed-by: Subhash Jadavani 
> >> >> >> >> Signed-off-by: Dolev Raviv 
> >> >> >> >> Signed-off-by: Gilad Broner 
> >> >> >> >> Signed-off-by: Yaniv Gardi 
> >> >> >> >
> >> >> >> > What tool is going to use this ioctl?  Why does userspcae want
> >> to
> >> >> do
> >> >> >> > something "special" with UFS devices?  Shouldn't they just be
> >> >> treated
> >> >> >> > like any other normal block device?
> >> >> >> >
> >> >> >>
> >> >> >> Any userspace application can be a tool.
> >> >> >> We already implemented and used a user space application, that
> >> sent
> >> >> >> queries to the UFS devices in order to get information and
> >> >> descriptors.
> >> >> >
> >> >> > But do you want to do with that information?  Why does userspace
> >> care?
> >> >> >
> >> >>
> >> >> i don't really understand the subtext of your question -
> >> >> as ANY ioctl cb, we decided to implement the ioctl callback of this
> >> scsi
> >> >> device in order to get information like UNIT DESC, DEVICE DESC,
> >> FLAGs,
> >> >> ATTRIBUTES.
> >> >> When dealing with UFS devices, one should be able to read the
> >> >> characteristics of the device. why ? well, why not ?
> >> >
> >> > Why aren't those characteristics just exported as sysfs attributes
> >> under
> >> > control by the UFS controller driver?  Why do you need/want an ioctl
> >> for
> >> > this?
> >> >
> >>
> >> Hi greg k-h,
> >>
> >> in our code, we used the IOCTL during runtime, in order to determine
> >> some
> >> information about the RPMB well known lun.
> >> with the rpmb lun ID we could then go to /dev/sgX and issue
> >> UFS_IOCTL_QUERY to this lun and get the data -
> >> reading the QUERY_DESC_IDN_GEOMETRY descriptor and reading the
> >> QUERY_DESC_IDN_UNIT descriptor.
> >>
> >> this was crucial to the work we do in RPMB.
> >
> > What is RPMB?
> >
> > And again, why not just use sysfs attributes on your host controller
> > device?  Why does this have to be a custom ioctl?
> >
> > greg k-h
> >
> 
> RPMB is spcial Logical Unit in the UFS device. you can read about it in
> the UFS spec. Greg, you are insisting on sysfs, but i can't implement it
> now, as i don't have the Hardware anymore, or the time.

If you don't have the hardware, how are you testing this patch?

And if you don't have the hardware I guess you don't need this change :)

> This is a tested and verified code that was accepted and reviewed already,
> so i'm not sure what is wrong with this solution, not to say, it's already
> implemented, tested and verified.
> hope you are help us push it.

That's a horrible reason to merge a patch that someone else is going to
have to support for 20+ years with an api that doesn't make much sense.

If you don't have the hardware, then this isn't needed.  But if you do,
then please look into using sysfs for this, as I think that should be
the correct interface here, again, not some random ioctl.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[ygardi]

> On Thu, Mar 10, 2016 at 03:52:54PM -, yga...@codeaurora.org wrote:
>> > On Wed, Mar 09, 2016 at 08:52:59PM -, yga...@codeaurora.org wrote:
>> >> > On Wed, Mar 09, 2016 at 07:09:49PM -, yga...@codeaurora.org
>> wrote:
>> >> >> > On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
>> >> >> >> This patch exposes the ioctl interface for UFS driver via SCSI
>> >> device
>> >> >> >> ioctl interface. As of now UFS driver would provide the ioctl
>> for
>> >> >> query
>> >> >> >> interface to connected UFS device.
>> >> >> >>
>> >> >> >> Reviewed-by: Subhash Jadavani 
>> >> >> >> Signed-off-by: Dolev Raviv 
>> >> >> >> Signed-off-by: Gilad Broner 
>> >> >> >> Signed-off-by: Yaniv Gardi 
>> >> >> >
>> >> >> > What tool is going to use this ioctl?  Why does userspcae want
>> to
>> >> do
>> >> >> > something "special" with UFS devices?  Shouldn't they just be
>> >> treated
>> >> >> > like any other normal block device?
>> >> >> >
>> >> >>
>> >> >> Any userspace application can be a tool.
>> >> >> We already implemented and used a user space application, that
>> sent
>> >> >> queries to the UFS devices in order to get information and
>> >> descriptors.
>> >> >
>> >> > But do you want to do with that information?  Why does userspace
>> care?
>> >> >
>> >>
>> >> i don't really understand the subtext of your question -
>> >> as ANY ioctl cb, we decided to implement the ioctl callback of this
>> scsi
>> >> device in order to get information like UNIT DESC, DEVICE DESC,
>> FLAGs,
>> >> ATTRIBUTES.
>> >> When dealing with UFS devices, one should be able to read the
>> >> characteristics of the device. why ? well, why not ?
>> >
>> > Why aren't those characteristics just exported as sysfs attributes
>> under
>> > control by the UFS controller driver?  Why do you need/want an ioctl
>> for
>> > this?
>> >
>>
>> Hi greg k-h,
>>
>> in our code, we used the IOCTL during runtime, in order to determine
>> some
>> information about the RPMB well known lun.
>> with the rpmb lun ID we could then go to /dev/sgX and issue
>> UFS_IOCTL_QUERY to this lun and get the data -
>> reading the QUERY_DESC_IDN_GEOMETRY descriptor and reading the
>> QUERY_DESC_IDN_UNIT descriptor.
>>
>> this was crucial to the work we do in RPMB.
>
> What is RPMB?
>
> And again, why not just use sysfs attributes on your host controller
> device?  Why does this have to be a custom ioctl?
>
> greg k-h
>

RPMB is spcial Logical Unit in the UFS device. you can read about it in
the UFS spec. Greg, you are insisting on sysfs, but i can't implement it
now, as i don't have the Hardware anymore, or the time.

This is a tested and verified code that was accepted and reviewed already,
so i'm not sure what is wrong with this solution, not to say, it's already
implemented, tested and verified.
hope you are help us push it.

thanks,
Yaniv

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Greg KH]

On Thu, Mar 10, 2016 at 03:52:54PM -, yga...@codeaurora.org wrote:
> > On Wed, Mar 09, 2016 at 08:52:59PM -, yga...@codeaurora.org wrote:
> >> > On Wed, Mar 09, 2016 at 07:09:49PM -, yga...@codeaurora.org wrote:
> >> >> > On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
> >> >> >> This patch exposes the ioctl interface for UFS driver via SCSI
> >> device
> >> >> >> ioctl interface. As of now UFS driver would provide the ioctl for
> >> >> query
> >> >> >> interface to connected UFS device.
> >> >> >>
> >> >> >> Reviewed-by: Subhash Jadavani 
> >> >> >> Signed-off-by: Dolev Raviv 
> >> >> >> Signed-off-by: Gilad Broner 
> >> >> >> Signed-off-by: Yaniv Gardi 
> >> >> >
> >> >> > What tool is going to use this ioctl?  Why does userspcae want to
> >> do
> >> >> > something "special" with UFS devices?  Shouldn't they just be
> >> treated
> >> >> > like any other normal block device?
> >> >> >
> >> >>
> >> >> Any userspace application can be a tool.
> >> >> We already implemented and used a user space application, that sent
> >> >> queries to the UFS devices in order to get information and
> >> descriptors.
> >> >
> >> > But do you want to do with that information?  Why does userspace care?
> >> >
> >>
> >> i don't really understand the subtext of your question -
> >> as ANY ioctl cb, we decided to implement the ioctl callback of this scsi
> >> device in order to get information like UNIT DESC, DEVICE DESC, FLAGs,
> >> ATTRIBUTES.
> >> When dealing with UFS devices, one should be able to read the
> >> characteristics of the device. why ? well, why not ?
> >
> > Why aren't those characteristics just exported as sysfs attributes under
> > control by the UFS controller driver?  Why do you need/want an ioctl for
> > this?
> >
> 
> Hi greg k-h,
> 
> in our code, we used the IOCTL during runtime, in order to determine some
> information about the RPMB well known lun.
> with the rpmb lun ID we could then go to /dev/sgX and issue
> UFS_IOCTL_QUERY to this lun and get the data -
> reading the QUERY_DESC_IDN_GEOMETRY descriptor and reading the
> QUERY_DESC_IDN_UNIT descriptor.
> 
> this was crucial to the work we do in RPMB.

What is RPMB?

And again, why not just use sysfs attributes on your host controller
device?  Why does this have to be a custom ioctl?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[ygardi]

> On Wed, Mar 09, 2016 at 08:52:59PM -, yga...@codeaurora.org wrote:
>> > On Wed, Mar 09, 2016 at 07:09:49PM -, yga...@codeaurora.org wrote:
>> >> > On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
>> >> >> This patch exposes the ioctl interface for UFS driver via SCSI
>> device
>> >> >> ioctl interface. As of now UFS driver would provide the ioctl for
>> >> query
>> >> >> interface to connected UFS device.
>> >> >>
>> >> >> Reviewed-by: Subhash Jadavani 
>> >> >> Signed-off-by: Dolev Raviv 
>> >> >> Signed-off-by: Gilad Broner 
>> >> >> Signed-off-by: Yaniv Gardi 
>> >> >
>> >> > What tool is going to use this ioctl?  Why does userspcae want to
>> do
>> >> > something "special" with UFS devices?  Shouldn't they just be
>> treated
>> >> > like any other normal block device?
>> >> >
>> >>
>> >> Any userspace application can be a tool.
>> >> We already implemented and used a user space application, that sent
>> >> queries to the UFS devices in order to get information and
>> descriptors.
>> >
>> > But do you want to do with that information?  Why does userspace care?
>> >
>>
>> i don't really understand the subtext of your question -
>> as ANY ioctl cb, we decided to implement the ioctl callback of this scsi
>> device in order to get information like UNIT DESC, DEVICE DESC, FLAGs,
>> ATTRIBUTES.
>> When dealing with UFS devices, one should be able to read the
>> characteristics of the device. why ? well, why not ?
>
> Why aren't those characteristics just exported as sysfs attributes under
> control by the UFS controller driver?  Why do you need/want an ioctl for
> this?
>

Hi greg k-h,

in our code, we used the IOCTL during runtime, in order to determine some
information about the RPMB well known lun.
with the rpmb lun ID we could then go to /dev/sgX and issue
UFS_IOCTL_QUERY to this lun and get the data -
reading the QUERY_DESC_IDN_GEOMETRY descriptor and reading the
QUERY_DESC_IDN_UNIT descriptor.

this was crucial to the work we do in RPMB.

thanks,
Yaniv

>> during development of this driver, it was useful in many cases to be
>> able
>> to communicate with the device, by simple IOCTL command, rather than
>> implementing ad-hock.
>
> Do other storage busses have these types of "custom" ioctls for their
> bus-type alone?  For simple attributes like this, shouldn't you be using
> sysfs instead so that it is much easier for userspace tools to get
> access to them?
>
> thanks,
>
> greg k-h
>


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Greg KH]

On Wed, Mar 09, 2016 at 08:52:59PM -, yga...@codeaurora.org wrote:
> > On Wed, Mar 09, 2016 at 07:09:49PM -, yga...@codeaurora.org wrote:
> >> > On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
> >> >> This patch exposes the ioctl interface for UFS driver via SCSI device
> >> >> ioctl interface. As of now UFS driver would provide the ioctl for
> >> query
> >> >> interface to connected UFS device.
> >> >>
> >> >> Reviewed-by: Subhash Jadavani 
> >> >> Signed-off-by: Dolev Raviv 
> >> >> Signed-off-by: Gilad Broner 
> >> >> Signed-off-by: Yaniv Gardi 
> >> >
> >> > What tool is going to use this ioctl?  Why does userspcae want to do
> >> > something "special" with UFS devices?  Shouldn't they just be treated
> >> > like any other normal block device?
> >> >
> >>
> >> Any userspace application can be a tool.
> >> We already implemented and used a user space application, that sent
> >> queries to the UFS devices in order to get information and descriptors.
> >
> > But do you want to do with that information?  Why does userspace care?
> >
> 
> i don't really understand the subtext of your question -
> as ANY ioctl cb, we decided to implement the ioctl callback of this scsi
> device in order to get information like UNIT DESC, DEVICE DESC, FLAGs,
> ATTRIBUTES.
> When dealing with UFS devices, one should be able to read the
> characteristics of the device. why ? well, why not ?

Why aren't those characteristics just exported as sysfs attributes under
control by the UFS controller driver?  Why do you need/want an ioctl for
this?

> during development of this driver, it was useful in many cases to be able
> to communicate with the device, by simple IOCTL command, rather than
> implementing ad-hock.

Do other storage busses have these types of "custom" ioctls for their
bus-type alone?  For simple attributes like this, shouldn't you be using
sysfs instead so that it is much easier for userspace tools to get
access to them?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[ygardi]

> On Wed, Mar 09, 2016 at 07:09:49PM -, yga...@codeaurora.org wrote:
>> > On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
>> >> This patch exposes the ioctl interface for UFS driver via SCSI device
>> >> ioctl interface. As of now UFS driver would provide the ioctl for
>> query
>> >> interface to connected UFS device.
>> >>
>> >> Reviewed-by: Subhash Jadavani 
>> >> Signed-off-by: Dolev Raviv 
>> >> Signed-off-by: Gilad Broner 
>> >> Signed-off-by: Yaniv Gardi 
>> >
>> > What tool is going to use this ioctl?  Why does userspcae want to do
>> > something "special" with UFS devices?  Shouldn't they just be treated
>> > like any other normal block device?
>> >
>>
>> Any userspace application can be a tool.
>> We already implemented and used a user space application, that sent
>> queries to the UFS devices in order to get information and descriptors.
>
> But do you want to do with that information?  Why does userspace care?
>

i don't really understand the subtext of your question -
as ANY ioctl cb, we decided to implement the ioctl callback of this scsi
device in order to get information like UNIT DESC, DEVICE DESC, FLAGs,
ATTRIBUTES.
When dealing with UFS devices, one should be able to read the
characteristics of the device. why ? well, why not ?
during development of this driver, it was useful in many cases to be able
to communicate with the device, by simple IOCTL command, rather than
implementing ad-hock.

regards,
Yaniv

>> Not only ioctl interface is a useful way to interact with the device,
>> we used it, and found it very helpful in varies cases.
>
> In what case was it helpful?  Why does userspace care about ufs
> specifics, it should just treat it like any other block device and not
> care at all.
>
> thanks,
>
> greg k-h
>


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Greg KH]

On Wed, Mar 09, 2016 at 07:09:49PM -, yga...@codeaurora.org wrote:
> > On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
> >> This patch exposes the ioctl interface for UFS driver via SCSI device
> >> ioctl interface. As of now UFS driver would provide the ioctl for query
> >> interface to connected UFS device.
> >>
> >> Reviewed-by: Subhash Jadavani 
> >> Signed-off-by: Dolev Raviv 
> >> Signed-off-by: Gilad Broner 
> >> Signed-off-by: Yaniv Gardi 
> >
> > What tool is going to use this ioctl?  Why does userspcae want to do
> > something "special" with UFS devices?  Shouldn't they just be treated
> > like any other normal block device?
> >
> 
> Any userspace application can be a tool.
> We already implemented and used a user space application, that sent
> queries to the UFS devices in order to get information and descriptors.

But do you want to do with that information?  Why does userspace care?

> Not only ioctl interface is a useful way to interact with the device,
> we used it, and found it very helpful in varies cases.

In what case was it helpful?  Why does userspace care about ufs
specifics, it should just treat it like any other block device and not
care at all.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[ygardi]

> On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
>> This patch exposes the ioctl interface for UFS driver via SCSI device
>> ioctl interface. As of now UFS driver would provide the ioctl for query
>> interface to connected UFS device.
>>
>> Reviewed-by: Subhash Jadavani 
>> Signed-off-by: Dolev Raviv 
>> Signed-off-by: Gilad Broner 
>> Signed-off-by: Yaniv Gardi 
>
> What tool is going to use this ioctl?  Why does userspcae want to do
> something "special" with UFS devices?  Shouldn't they just be treated
> like any other normal block device?
>

Any userspace application can be a tool.
We already implemented and used a user space application, that sent
queries to the UFS devices in order to get information and descriptors.
Not only ioctl interface is a useful way to interact with the device,
we used it, and found it very helpful in varies cases.
hence, this patch.
This patch has been already addressed all comments of Arnd Bergman from 5
months ago, and now, re-uploaded again.

thanks,
Yaniv

> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[ygardi]

> On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
>> This patch exposes the ioctl interface for UFS driver via SCSI device
>> ioctl interface. As of now UFS driver would provide the ioctl for query
>> interface to connected UFS device.
>>
>> Reviewed-by: Subhash Jadavani 
>> Signed-off-by: Dolev Raviv 
>> Signed-off-by: Gilad Broner 
>> Signed-off-by: Yaniv Gardi 
>
> What tool is going to use this ioctl?  Why does userspcae want to do
> something "special" with UFS devices?  Shouldn't they just be treated
> like any other normal block device?
>

Any userspace application can be a tool.
We already implemented and used a user space application, that sent
queries to the UFS devices in order to get information and descriptors.
Not only ioctl interface is a useful way to interact with the device,
we used it, and found it very helpful in varies cases.
hence, this patch.
This patch has been already addressed all comments of Arnd Bergman from 5
months ago, and now, re-uploaded again.

thanks,
Yaniv

> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] scsi: ufs: add ioctl interface for query request

[Greg KH]

On Wed, Mar 09, 2016 at 04:11:33PM +0200, Yaniv Gardi wrote:
> This patch exposes the ioctl interface for UFS driver via SCSI device
> ioctl interface. As of now UFS driver would provide the ioctl for query
> interface to connected UFS device.
> 
> Reviewed-by: Subhash Jadavani 
> Signed-off-by: Dolev Raviv 
> Signed-off-by: Gilad Broner 
> Signed-off-by: Yaniv Gardi 

What tool is going to use this ioctl?  Why does userspcae want to do
something "special" with UFS devices?  Shouldn't they just be treated
like any other normal block device?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html