linux-kernel - Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel

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]

Date:	Tue, 23 Oct 2012 15:54:25 -0700
From:	Dan Williams <djbw@...com>
To:	Matt Porter <mporter@...com>
Cc:	Vinod Koul <vinod.koul@...el.com>, Chris Ball <cjb@...top.org>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux MMC List <linux-mmc@...r.kernel.org>
Subject: Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

On Thu, Oct 18, 2012 at 7:51 PM, Matt Porter <mporter@...com> wrote:
> Add a dmaengine API to retrieve per channel capabilities.
> Currently, only channel ops and SG segment limitations are
> implemented caps.
>
> The API is optionally implemented by drivers and when
> unimplemented will return a NULL pointer. It is intended
> to be executed after a channel has been requested and, if
> the channel is intended to be used with slave SG transfers,
> then it may only be called after dmaengine_slave_config()
> has executed. The slave driver provides parameters such as
> burst size and address width which may be necessary for
> the dmaengine driver to use in order to properly return SG
> segment limit caps.
>
> Suggested-by: Vinod Koul <vinod.koul@...el.com>
> Signed-off-by: Matt Porter <mporter@...com>
> ---
>  include/linux/dmaengine.h |   52 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 11d9e25..0181887 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -371,6 +371,38 @@ struct dma_slave_config {
>         unsigned int slave_id;
>  };
>
> +enum dmaengine_apis {
> +       DMAENGINE_MEMCPY        = 0x0001,
> +       DMAENGINE_XOR           = 0x0002,
> +       DMAENGINE_XOR_VAL       = 0x0004,
> +       DMAENGINE_PQ            = 0x0008,
> +       DMAENGINE_PQ_VAL        = 0x0010,
> +       DMAENGINE_MEMSET        = 0x0020,
> +       DMAENGINE_SLAVE         = 0x0040,
> +       DMAENGINE_CYCLIC        = 0x0080,
> +       DMAENGINE_INTERLEAVED   = 0x0100,
> +       DMAENGINE_SG            = 0x0200,
> +};
> +
> +/* struct dmaengine_chan_caps - expose capability of a channel
> + * Note: each channel can have same or different capabilities
> + *
> + * This primarily classifies capabilities into
> + * a) APIs/ops supported
> + * b) channel physical capabilities
> + *
> + * @ops: or'ed api capability
> + * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
> + *         channel (0 for no maximum or not a SG/SLAVE channel)
> + * @seg_len: maximum length of SG segments supported on a SG/SLAVE
> + *          channel (0 for no maximum or not a SG/SLAVE channel)
> + */
> +struct dmaengine_chan_caps {
> +       enum dmaengine_apis ops;
> +       int seg_nr;
> +       int seg_len;
> +};

This makes sense for the potentially dynamic capability properties
that get set after configuration, but why do we need the operation
types here?  They can be retrieved from the parent device.

--
Dan
--
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/