On Wed, Jan 6, 2016 at 7:01 PM, Vishal Verma <vishal@xxxxxxxxxx> wrote: > On Wed, 2016-01-06 at 12:12 -0500, Linda Knippers wrote: >> On 1/4/2016 5:34 PM, Vishal Verma wrote: >> > Normally, if a platform does not advertise support for Address >> > Range >> > Scrub (ARS), we skip it. But if ARS is advertised, it is expected >> > to >> > always succeed. If it fails, we normally fail initialization at >> > that >> > point. >> > >> > Add a module parameter to nfit that lets it ignore ARS failures and >> > continue with initialization for debugging. >> >> Could ARS be so broken that you might want to just ignore it >> altogether >> and not even make the requests? >> > > That is a possibility, and I considered it, but I thought it might be > better to see how it fails and then just ignore the errors.. > It boils down to how much we trust the firmware, and hopefully if it > advertises ARS as implemented, it should not be completely broken.. > > Dan, thoughts? > Hmm, once we add plumbing for bad block clearing / setting we'll have the tools to workaround firmware with untrusted ars results. i.e. just manually correct false positive / negative entries. -- 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
