On Thu, Jul 21, 2016 at 12:55 PM, Linda Knippers <linda.knippers@xxxxxxx> wrote: > > > On 7/21/2016 3:46 PM, Dan Williams wrote: >> On Thu, Jul 21, 2016 at 12:40 PM, Linda Knippers <linda.knippers@xxxxxxx> wrote: >>> On 07/20/2016 09:50 PM, Vishal Verma wrote: >>>> Normally, an ARS (Address Range Scrub) only happens at >>>> boot/initialization time. There can however arise situations where a >>>> bus-wide rescan is needed - notably, in the case of discovering a latent >>>> media error, we should do a full rescan to figure out what other sectors >>>> are bad, and thus potentially avoid triggering an mce on them in the >>>> future. Also provide a sysfs trigger to start a bus-wide scrub. >>> >>> I don't see anything in here that checks to see if the platform actually >>> supports ARS before setting all this stuff up. Setting up an MCE handler >>> and exposing a sysfs trigger for something that is optional and perhaps >>> not implemented doesn't seem helpful. Or is there a check that I missed? >> >> We'll get -ENOTTY to ars_start(), but you're right it's a good idea to >> hide the scrub attribute if a platform does not have ars support. >> >> Vishal, can you add an is_visible() routine to >> acpi_nfit_attribute_group() to hide 'scrub' on platforms that do not >> implement the ARS commands? > > It's also possible that a platform might only support ARS at boot time > so subsequent scrubs would fail or not return any new information. > I don't think there's a way to know that in advice though. I would hope a platform like that just marks the "ARS - Start" command as not supported so that we don't even generate the failure. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
