Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934252AbcCIWrX (ORCPT ); Wed, 9 Mar 2016 17:47:23 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:59616 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754064AbcCIWrR (ORCPT ); Wed, 9 Mar 2016 17:47:17 -0500 Date: Wed, 9 Mar 2016 14:47:16 -0800 From: Greg KH To: ygardi@codeaurora.org Cc: james.bottomley@hansenpartnership.com, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org, santoshsy@gmail.com, linux-scsi-owner@vger.kernel.org, Dolev Raviv , Gilad Broner , Vinayak Holikatti , "James E.J. Bottomley" , "Martin K. Petersen" , Michael Neuling , "Matthew R. Ochs" , Wen Xiong , Subhash Jadavani , "open list:ABI/API" Subject: Re: [PATCH v7] scsi: ufs: add ioctl interface for query request Message-ID: <20160309224716.GA30523@kroah.com> References: <1457532699-11487-1-git-send-email-ygardi@codeaurora.org> <20160309162943.GC21181@kroah.com> <43117fbc4f3a305acd0f4975a633934a.squirrel@us.codeaurora.org> <20160309201808.GA24568@kroah.com> <551d9d1ae5418dd2dfa91aa6db69deb9.squirrel@us.codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551d9d1ae5418dd2dfa91aa6db69deb9.squirrel@us.codeaurora.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2079 Lines: 48 On Wed, Mar 09, 2016 at 08:52:59PM -0000, ygardi@codeaurora.org wrote: > > On Wed, Mar 09, 2016 at 07:09:49PM -0000, ygardi@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