On Thu, Jan 7, 2016 at 1:31 PM, Linda Knippers <linda.knippers@xxxxxxx> wrote: > On 1/7/2016 12:34 AM, Dan Williams wrote: >> 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. > > I was more worried about places where the code is looping waiting > for commands to complete and what happens with buggy firmware > but I've now commented on that patch. Related to the parameter, > if we think we need to account for buggy firmware, we could be > vulnerable in more places this. Yes, lets wait and see rather than pre-emptively working around potentially bad firmware. -- 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
