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: <56583B95.7060503@ti.com>
Date:	Fri, 27 Nov 2015 13:16:37 +0200
From:	Peter Ujfalusi <peter.ujfalusi@...com>
To:	Arnd Bergmann <arnd@...db.de>,
	<linux-arm-kernel@...ts.infradead.org>
CC:	<vinod.koul@...el.com>, <andy.shevchenko@...il.com>,
	<linux-mmc@...r.kernel.org>, <nsekhar@...com>,
	<linux-kernel@...r.kernel.org>, <dmaengine@...r.kernel.org>,
	<linux-omap@...r.kernel.org>
Subject: Re: [RFC 3/6] dmaengine: core: Introduce new, universal API to
 request a channel

On 11/27/2015 01:00 PM, Arnd Bergmann wrote:
> On Friday 27 November 2015 10:29:39 Peter Ujfalusi wrote:
>> struct dma_chan *dma_request_chan(struct device *dev, const char *name,
>> 				  const dma_cap_mask_t *mask);
>> To request a slave channel. The mask parameter is optional and it is used
>> to check if the received channel's capabilities can satisfy the requested
>> mask. The dma_request_chan() will try to find the channel via DT, ACPI or
>> in case if the kernel booted in non DT/ACPI mode it will use a filter
>> lookup table and retrieves the RESOURCE_DMA from the requester's device.
>> This legacy mode needs changes in platform code, in dmaengine drivers and
>> finally the dmaengine user drivers can be converted:
> 
> I think we should not introduce the mask parameter at all. In the rare
> case that we actually need to pass a mask other than DMA_SLAVE today,
> we should be able to encode that in the data we pass to the filter
> function.

I have seen that drivers check the capabilities themselves after getting the
channel, so I thought that if we move that also to the core we can save on
duplicated lines around the kernel. It is not needed to get the channel. As
you can see in the mmc patch, I pass NULL and the channel I got is the correct
one.
Sure, I can remove it.

>> RESOURCE_DMA needs to be added to the platform devices with names
>>
>> For each dmaengine driver a string array listing the devices handled by the
>> given DMA driver:
>>
>> static char *da8xx_edma0_devices[] = {
>> 	"davinci-mcasp.0",
>> 	"da830-mmc.0",
>> };
>>
>> This information is going to be needed by the dmaengine driver, so
>> modification to the platform_data is needed, and the driver map should be
>> added to the pdata of the DMA driver:
> 
> However, a lot of drivers definitely need to pass a data pointer for
> each device. I see that you currently rely on the IORESOURCE_DMA
> method that a couple of platforms use today, but I think it would
> be backwards to do it that way for the platforms that require passing
> more than an integer number today.
> 
> Having a pointer as the filter function argument is intentional and I'd
> prefer to change the platforms that currently use IORESOURCE_DMA (davinci,
> pxa, omap1, blackfin, alchemy) to stop doing it instead, and return
> IORESOURCE_DMA to its original meaning that was limited to ISAPNP style
> devices not using the dmaengine API.

Something like this:

/* include/linux/dmaengine.h */

struct dma_filter_map {
	char *devname;
	char *slave;
	void *param;
};

struct dma_filter {
	dma_filter_fn filter_fn;
	int mapcnt;
	struct dma_filter_map *map;
};

/* arch/arm/mach-davinci/devices-da8xx.c */

static struct dma_filter_map da8xx_edma0_map[] = {
	{
		.devname = "davinci-mcasp.0",
		.slave = "tx",
		.param = (void*)DAVINCI_DA8XX_DMA_MCASP0_AXEVT,
	},
	{
		.devname = "davinci-mcasp.0",
		.slave = "rx",
		.param = (void*)DAVINCI_DA8XX_DMA_MCASP0_AREVT,
	},
	{
		.devname = "da830-mmc.0",
		.slave = "tx",
		.param = (void*)DA8XX_DMA_MMCSD0_TX,
	},
	{
		.devname = "da830-mmc.0",
		.slave = "rx",
		.param = (void*)DA8XX_DMA_MMCSD0_RX,
	},
};

I had this version first, but decided to go with a simpler one present in this
RFC series.

-- 
Péter
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ