linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org, Jean Delvare <jdelvare@suse.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH 0/1] Summary: hwmon driver for temperature sensors on SATA drives
Date: Tue, 10 Dec 2019 23:08:04 -0500	[thread overview]
Message-ID: <yq15zinmrmj.fsf@oracle.com> (raw)
In-Reply-To: <20191209052119.32072-1-linux@roeck-us.net> (Guenter Roeck's message of "Sun, 8 Dec 2019 21:21:18 -0800")


Hi Guenter,

> The most recent attempt was [1] by Linus Walleij. It went through a total
> of seven iterations. At the end, it was rejected for a number of reasons;
> see the provided link for details. This implementation resides in the
> SCSI core. It originally resided in libata but was moved to SCSI per
> maintainer request, where it was ultimately rejected.

While I am sure I come across as a curmudgeon, regressions is a major
concern for me. That, and making sure we pick the right architecture. I
thought we were making good progress in that department when Linus
abandoned the effort.

> The feedback on this approach suggests to use the SCSI Temperature log
> page [0x0d] as means to access drive temperature information. It is
> unknown if this is implemented in any real SCSI drive.

Almost every SCSI drive has it.

> The feedback also suggests to obtain temperature from ATA drives,
> convert it into the SCSI temperature log page in libata-scsi, and to
> use that information in a hardware monitoring driver. The format and
> method to do this is documented in [3]. This is not currently
> implemented in the Linux kernel.

Correct, but I have no qualms over exporting the SCSI temperature log
page. The devices that export that page are generally well-behaved.

My concerns are wrt. identifying whether SMART data is available for
USB/UAS. I am not too worried about ATA and "real" SCSI (ignoring RAID
controllers that hide the real drives in various ways).

I am not sure why the SCSI temperature log page parsing would be
complex. I will have to go check smartmontools to see what that is all
about. The spec is as simple as can be.

Anyway. I think the overall approach wrt. SCT and falling back to
well-known SMART fields is reasonably sane and fine for libata. But I
don't understand the pushback wrt. using the SCSI temperature log page
as a conduit. I think it would be fine if this worked out of the box for
both SCSI and ATA drives.

The elephant in the room remains USB. And coming up with a way we can
reliably detect whether it is safe to start poking at the device to
discover if SMART is provided. If we eventually want to pursue USB, I
think your heuristic stuff needs to be a library that can be leveraged
by both libata and USB. But that doesn't have to be part of the initial
effort.

And finally, my concerns wrt. reacting to bad sensors remain. Not too
familiar with hwmon, but I would still like any actions based on
reported temperatures to be under user control and not the kernel.

-- 
Martin K. Petersen	Oracle Linux Engineering

  parent reply	other threads:[~2019-12-11  4:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-09  5:21 [PATCH 0/1] Summary: hwmon driver for temperature sensors on SATA drives Guenter Roeck
2019-12-09  5:21 ` [PATCH 1/1] hwmon: Driver " Guenter Roeck
2019-12-09  5:28   ` Randy Dunlap
2019-12-09  6:00     ` Guenter Roeck
2019-12-09 17:08   ` Bart Van Assche
2019-12-09 19:20     ` Guenter Roeck
2019-12-10 16:10       ` Bart Van Assche
2019-12-12 22:33   ` Linus Walleij
2019-12-12 23:21     ` Martin K. Petersen
2019-12-13  4:18       ` Guenter Roeck
2019-12-17  2:47         ` Martin K. Petersen
2019-12-17  4:20           ` Guenter Roeck
2019-12-18  3:39             ` Martin K. Petersen
2019-12-11  4:08 ` Martin K. Petersen [this message]
2019-12-11  5:57   ` [PATCH 0/1] Summary: hwmon driver " Guenter Roeck
2019-12-17  2:35     ` Martin K. Petersen
2019-12-17  3:57       ` Guenter Roeck
2019-12-17  5:50         ` Damien Le Moal
2019-12-17 15:47           ` Guenter Roeck
2019-12-18  3:42         ` Martin K. Petersen

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=yq15zinmrmj.fsf@oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=jdelvare@suse.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /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;
as well as URLs for NNTP newsgroup(s).