linux-kernel - Re: [RFC/PARTIAL PATCH 1/3] dma: create linux/dma-direction.h

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, 8 Jan 2008 09:58:31 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	akepner@....com
Cc:	Tony Luck <tony.luck@...el.com>,
	Grant Grundler <grundler@...isc-linux.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Jes Sorensen <jes@....com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Roland Dreier <rdreier@...co.com>,
	James Bottomley <James.Bottomley@...eleye.com>,
	David Miller <davem@...emloft.net>,
	Muli Ben-Yehuda <muli@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC/PARTIAL PATCH 1/3] dma: create linux/dma-direction.h


* akepner@....com <akepner@....com> wrote:

> +enum dma_data_attr {
> +	DMA_ATTR_BARRIER = (1 << 0),
> +	DMA_ATTR_FOO = (1 << 1),
> +	DMA_ATTR_GOO = (1 << 2),
> +	DMA_ATTR_MAX = (1 << 3),
> +};

FOO/GOO we dont need i guess ...

> +#define DMA_FLAGS_ATTR_SHIFT	8
> +#define DMA_FLAGS_DIR_MASK	((1 << DMA_FLAGS_ATTR_SHIFT) - 1)
> +#define DMA_FLAGS_ATTR_MASK	~DMA_FLAGS_DIR_MASK
> +
> +static inline enum dma_data_direction dma_flags_get_dir(u32 fin)
> +{
> +	return (fin & DMA_FLAGS_DIR_MASK);
> +}

the u32 looks a bit weird. Why not unsigned int ?

also, are the new dma_map_*() API compatible with the old one? I.e. does 
dma_map_*(...,0) and dma_map_*(...,1) map to the right thing? If yes 
then perhaps dont change 'int direction' to 'u32 flags' at all but just 
rename 'direction' to 'flags' and be done with it.

also, this conversion:

+       enum dma_data_direction direction = dma_flags_get_dir(flags);

would be unnecessary if callers passed in the bitmap already, instead of 
'flags'. 0 and 1 would still map to the right thing i think.

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