[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5638E0A5.4060401@codeaurora.org>
Date: Tue, 3 Nov 2015 11:28:21 -0500
From: Sinan Kaya <okaya@...eaurora.org>
To: Vinod Koul <vinod.koul@...el.com>,
Timur Tabi <timur@...eaurora.org>
Cc: dmaengine@...r.kernel.org, cov@...eaurora.org, jcm@...hat.com,
Dan Williams <dan.j.williams@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions
On 11/3/2015 11:10 AM, Vinod Koul wrote:
> On Tue, Nov 03, 2015 at 08:31:57AM -0600, Timur Tabi wrote:
>> Sinan Kaya wrote:
>>>
>>> Almost all DMA engine drivers come with some sort of selftest code
>>> called from probe. I followed the same design pattern.
>>
>> As others have said, it appears that's outdated.
>>
>> Is there a real possibility that the hardware could fail the test
>> without trashing the system? It seems that if the DMA engine is
>> faulty, it won't "politely" fail. The whole system will crash or
>> some memory will get corrupted and you won't know it.
>
> Failing politely would be right thing to do. If DMA starts sending data to
> anywhere in system memory due to bug or wrong addresses we can't do
> anything to prevent that
>
I have seen failures in three cases so far. These are the reasons, why I
want to keep these runtime tests around.
1. Bug in ARM64 DMA subsystem.
2. Bug in IOMMU driver.
3. Bug in another newly introduced driver. The new driver would hog the
CPU and won't allow HIDMA interrupts to execute. Therefore, the test
times out.
In my code, when test fails; I abort all transactions in flight and
shutdown and deregister the HIDMA driver.
Of course, there is a small window of oppurtunity; where DMA can dump
data to incorrect place if HW was faulty right before I abort the
transaction.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists