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

[Greg KH]

On Thu, Mar 10, 2016 at 06:48:54PM -0000, ygardi@xxxxxxxxxxxxxx wrote:
> > On Thu, Mar 10, 2016 at 04:29:55PM -0000, ygardi@xxxxxxxxxxxxxx wrote:
> >> > On Thu, Mar 10, 2016 at 03:52:54PM -0000, ygardi@xxxxxxxxxxxxxx wrote:
> >> >> > On Wed, Mar 09, 2016 at 08:52:59PM -0000, ygardi@xxxxxxxxxxxxxx
> >> wrote:
> >> >> >> > On Wed, Mar 09, 2016 at 07:09:49PM -0000, ygardi@xxxxxxxxxxxxxx
> >> >> 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 <subhashj@xxxxxxxxxxxxxx>
> >> >> >> >> >> Signed-off-by: Dolev Raviv <draviv@xxxxxxxxxxxxxx>
> >> >> >> >> >> Signed-off-by: Gilad Broner <gbroner@xxxxxxxxxxxxxx>
> >> >> >> >> >> Signed-off-by: Yaniv Gardi <ygardi@xxxxxxxxxxxxxx>
> >> >> >> >> >
> >> >> >> >> > 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 this code, let's just drop it.  Feel free
to revisit it sometime in the future if you ever get hardware and need
this again.

thanks,

greg k-h