From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Avri Altman <Avri.Altman@wdc.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Jaegeuk Kim <jaegeuk@google.com>,
Alex Lemberg <Alex.Lemberg@wdc.com>,
Stanislav Nijnikov <Stanislav.Nijnikov@wdc.com>
Subject: Re: [PATCH 2/2 v4] scsi: ufs: introduce sysfs entries exposing UFS health info
Date: Wed, 27 Dec 2017 14:10:52 +0100 [thread overview]
Message-ID: <20171227131052.GA13384@kroah.com> (raw)
In-Reply-To: <DM5PR04MB10856CCEE145B2B8AADDF668FC070@DM5PR04MB1085.namprd04.prod.outlook.com>
On Wed, Dec 27, 2017 at 09:00:10AM +0000, Avri Altman wrote:
>
>
> > -----Original Message-----
> > From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> > owner@vger.kernel.org] On Behalf Of Greg Kroah-Hartman
> > Sent: Thursday, December 21, 2017 10:00 AM
> > To: Jaegeuk Kim <jaegeuk@kernel.org>
> > Cc: linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org; Jaegeuk Kim
> > <jaegeuk@google.com>
> > Subject: Re: [PATCH 2/2 v4] scsi: ufs: introduce sysfs entries exposing UFS
> > health info
> >
> > On Wed, Dec 20, 2017 at 02:13:25PM -0800, Jaegeuk Kim wrote:
> > > This patch adds a new sysfs group, namely health, via:
> > >
> > > /sys/devices/soc/X.ufshc/health/
> As device health is just one piece of information out of the device management,
> I think that you should address this in a more comprehensive way,
> And set hooks for much more device info:
> Allow access to device descriptors, attributes and flags.
Add on patches are easy to create for this if people really want and
need it :)
> The attributes and flags should be placed in separate subfolders
Why? What is that going to help with?
> The LUN specific descriptors and attributes should be placed in a luns
> subfolder, and then per descriptor / attribute type
Again, why?
> You might also would like to consider differentiating read and write -
> to control those type of accesses as well.
What do you mean by this exactly?
As it is, this is a step forward in getting attributes that people are
asking for and already using, into the kernel tree. Please don't object
because not all attributes that are possible are being added here, it
should be trivial to add more as needed, right?
I'm really tired of seeing all of the various out-of-tree forks of this
driver, it's about time that someone works to get those features merged,
right?
thanks,
greg k-h
next prev parent reply other threads:[~2017-12-27 13:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-20 19:16 [PATCH 1/2 v3] scsi: ufs: introduce static sysfs entries Jaegeuk Kim
2017-12-20 19:16 ` [PATCH 2/2 v3] scsi: ufs: introduce sysfs entries exposing UFS health info Jaegeuk Kim
2017-12-20 22:13 ` [PATCH 2/2 v4] " Jaegeuk Kim
2017-12-21 7:59 ` Greg Kroah-Hartman
2017-12-27 9:00 ` Avri Altman
2017-12-27 13:10 ` Greg Kroah-Hartman [this message]
2017-12-28 20:10 ` Jaegeuk Kim
2017-12-20 19:20 ` [PATCH 1/2 v3] scsi: ufs: introduce static sysfs entries Bart Van Assche
2017-12-20 20:16 ` Jaegeuk Kim
2017-12-21 2:37 ` Martin K. Petersen
2017-12-21 7:59 ` gregkh
2017-12-21 7:59 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171227131052.GA13384@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Alex.Lemberg@wdc.com \
--cc=Avri.Altman@wdc.com \
--cc=Stanislav.Nijnikov@wdc.com \
--cc=jaegeuk@google.com \
--cc=jaegeuk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox