linux-kernel - RE: [PATCH RFC] dmaengine: dw-edma: Decouple dw-edma-core.c from struct pci

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM5PR12MB127673CFDCA38A47E6F6F4DBDADB0@DM5PR12MB1276.namprd12.prod.outlook.com>
Date:   Wed, 15 Apr 2020 20:57:53 +0000
From:   Gustavo Pimentel <Gustavo.Pimentel@...opsys.com>
To:     Alan Mikhak <alan.mikhak@...ive.com>
CC:     "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "kishon@...com" <kishon@...com>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>
Subject: RE: [PATCH RFC] dmaengine: dw-edma: Decouple dw-edma-core.c from
 struct pci_dev

Hi Alan,

> > > At the moment, pci-epf-test grabs the first available dma channel on the
> > > endpoint side and uses it for either read, write, or copy operation. it is not
> > > possible at the moment to specify which dma channel to use on the pcitest
> > > command line. This may be possible by modifying the command line option
> > > -D to also specify the name of one or more dma channels.
> >
> > I'm assuming that behavior is due to your code, right? I'm not seen that
> > behavior on the Kernel tree.
> > Check my previous suggestion, it should be something similar to what is
> > been done while you select the MSI/MSI-X interrupt to trigger.
> 
> I believe this behavior exists in the kernel tree because the call to
> dma_request_chan_by_mask() always specifies channel zero. The user
> of pcitest has no way of specifying which one of the available dma channels
> to use.

I think we were discussing different things. I was referring to the 
pci-epf-test code, that I wasn't being able to find any instruction to 
call the DMA driver which had the described behavior.

I think you can do it by doing this:

Pseudo code:

#define EDMA_TEST_CHANNEL_NAME			"dma%uchan%u"

static bool dw_edma_test_filter(struct dma_chan *chan, void *filter)
{
	if (strcmp(dev_name(chan->device->dev), EDMA_TEST_DEVICE_NAME) || 
strcmp(dma_chan_name(chan), filter))
		return false;

	return true;
}

static void dw_edma_test_thread_create(int id, int channel)
{
	struct dma_chan *chan;
	dma_cap_mask_t mask;
	char filter[20];

	dma_cap_zero(mask);
	dma_cap_set(DMA_SLAVE, mask);
	dma_cap_set(DMA_CYCLIC, mask);

	snprintf(filter, sizeof(filter), EDMA_TEST_CHANNEL_NAME, id, 
channel);
	chan = dma_request_channel(mask, dw_edma_test_filter, filter);

	[..]
}

> I believe this behavior exists in the kernel tree because the call to
> dma_request_chan_by_mask() happens during the execution of
> pci_epf_test_bind() and the call to dma_release_channel() happens
> during the execution of pci_epf_test_unbind(). As long as pci-epf-test
> is bound, I cannot use another program such as dmatest from the
> endpoint-side command prompt to exercise the same channel.

Ok, I understood it now. Right, you can't use the dmatest here, even 
because, as far as I know, it is only MEM TO MEM operations and we need 
DEVICE_TO_MEM and vice-versa.

> 
> What I was suggesting is perhaps pci-epf-test can be modified to
> acquire and release the channel on each call to pci_epf_test_read(),
> ...write(), or ...copy() when the pcitest user specifies -D option.

Right, you are on the right track.
Perhaps you could take a look at patch [1] that I have done some time ago 
for testing the eDMA, I think you have all the tools/guideline there to 
do this adaption.
Another thing, 

[1] https://patchwork.kernel.org/patch/10760521/