lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 4 Nov 2015 21:42:46 -0500 From: Sinan Kaya <okaya@...eaurora.org> To: Vinod Koul <vinod.koul@...el.com>, Andy Shevchenko <andy.shevchenko@...il.com> Cc: Dan Williams <dan.j.williams@...el.com>, "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>, timur@...eaurora.org, cov@...eaurora.org, jcm@...hat.com, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions On 11/3/2015 11:08 AM, Vinod Koul wrote: > On Tue, Nov 03, 2015 at 10:22:25AM +0200, Andy Shevchenko wrote: >> On Tue, Nov 3, 2015 at 9:44 AM, Dan Williams <dan.j.williams@...el.com> wrote: >>> On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul <vinod.koul@...el.com> wrote: >>>> On Mon, Nov 02, 2015 at 11:18:37PM -0500, Sinan Kaya wrote: >>>>> On 11/2/2015 11:15 PM, Vinod Koul wrote: >>>>>> On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote: >> >> >>>>> This one; on the other hand, is selftest to verify hardware is >>>>> working as expected during power up. >> >> I prefer to have such nice case by run time parameter (let's say >> common to all DMA Engine drivers) >> >>>> We can have common code which is used for dmatest as well as selftest. I do >>>> not want to see same code duplicated.. >> >> First thought was to merge this to dmatest, however, some DMA >> controllers doesn't have a memcpy capability. > > The tests should be based on capablity of memcpy > >> How would we test them? Here is what I proposed. - a common file that gets compiled into a module that wants to use self-test with a public API. It can be called from driver's probe routine. - the test is independent of my implementation. It uses dmaengine API and should be portable to most drivers. - there *are* still drivers in the kernel that has selftest code embedded inside them. I followed the design pattern from other drivers thinking this must have been a good idea and it paid off for me. As far as I understand, there is interest in doing more than this and reusing the dmatest code for code duplication. Facts: - Dmatest can be actually configured to run during boot. - Nobody besides the dma driver developer uses dmatest. This leaves holes for regressions that are really hard to debug due to interaction with the rest of the system. - Dmatest doesn't exist in most distribution kernels. If we want to do something else, I need clear directions. I can remove the self test code completely from my driver. But, I need an equivalent functionality. > > That part is tricky, you need to do so thru clients, spi/audio/serial etc > My selftest code actually attaches to all slave devices and issues a memcpy command and then detaches from the slave devices. -- 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