Messages in this thread | | | Subject | Re: [PATCH 0/1] Summary: hwmon driver for temperature sensors on SATA drives | From | Guenter Roeck <> | Date | Mon, 16 Dec 2019 19:57:31 -0800 |
| |
On 12/16/19 6:35 PM, Martin K. Petersen wrote: > > Guenter, > >> If and when drives are detected which report bad information, such >> drives can be added to a blacklist without impact on the core SCSI or >> ATA code. Until that happens, not loading the driver solves the >> problem on any affected system. > > My only concern with that is that we'll have blacklisting several > places. We already have ATA and SCSI blacklists. If we now add a third > place, that's going to be a maintenance nightmare. > > More on that below. > >>> 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). > > OK, so I spent my weekend tinkering with 15+ years of accumulated USB > devices. And my conclusion is that no, we can't in any sensible manner, > support USB storage monitoring in the kernel. There is no heuristic that > I can find that identifies that "this is a hard drive or an SSD and > attempting one of the various SMART methods may be safe". As opposed to > "this is a USB key that's likely to lock up if you try". And that's > ignoring the drives with USB-ATA bridges that I managed to wedge in my > attempt at sending down commands. > > Even smartmontools is failing to work on a huge part of my vintage > collection. Thanks to a wide variety of bridges with random, custom > interfaces. > > So my stance on all this is that I'm fine with your general approach for > ATA. I will post a patch adding the required bits for SCSI. And if a > device does not implement either of the two standard methods, people > should use smartmontools. > > Wrt. name, since I've added SCSI support, satatemp is a bit of a > misnomer. drivetemp, maybe? No particular preference. > Agreed, if we extend this to SCSI, satatemp is less than perfect. drivetemp ? disktemp ? I am open to suggestions, with maybe a small personal preference for disktemp out of those two.
>> The one USB/UAS connected SATA drive I have (a WD passport) reports >> itself as "WD ", not as "ATA ". I would expect other drives >> to do the same. > > Yes. Most vendors are too fond of their brand names to put "ATA" in > there. So my suggestion is to relax the heuristic to trigger on the ATA > Information VPD page only and ignore the name. >
Fine with me. I wanted to be as restrictive as possible.
> Also, there are some devices that will lock up the way you access that > VPD page. So a tweak is also required there. > Do you have details ? Do I need to add a call to scsi_device_supports_vpd(), maybe ?
> To avoid the multiple blacklists and heuristic collections my suggestion > is that I introduce a helper function in SCSI (based on what I did in > the disk driver) that can be called to identify whether something is an > ATA device. And then the hwmon driver can call that and we can keep the > heuristics in one place. > > If a device turns out to be problematic wrt. getting the ATA VPD for the > purpose of SMART, for instance, it will also need to be blacklisted for > other reasons in SCSI. So I would really like to keep the heuristics in > one place. > Fine with me. My only concern is that I don't want the driver to disappear into nowhere-land (again).
Thanks, Guenter
| |