From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Joerg Roedel <joro@8bytes.org>,
Andrew Morton <akpm@linux-foundation.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Michal Hocko <mhocko@suse.com>,
Mel Gorman <mgorman@techsingularity.net>,
Arnd Bergmann <arnd@arndb.de>, Andy Lutomirski <luto@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
xen-devel@lists.xenproject.org, dri-devel@lists.freedesktop.org,
linux-samsung-soc@vger.kernel.org,
iommu@lists.linux-foundation.org, hch@infradead.org,
sstabellini@kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [RFC v2] dma-mapping: Use unsigned long for dma_attrs
Date: Wed, 01 Jun 2016 08:08:11 +0200 [thread overview]
Message-ID: <574E7BCB.6040505@samsung.com> (raw)
In-Reply-To: <20160531181533.GD11300@char.us.oracle.com>
On 05/31/2016 08:15 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
>> The dma-mapping core and the implementations do not change the
>> DMA attributes passed by pointer. Thus the pointer can point to const
>> data. However the attributes do not have to be a bitfield. Instead
>> unsigned long will do fine:
>>
>> 1. This is just simpler. Both in terms of reading the code and setting
>> attributes. Instead of initializing local attributes on the stack and
>> passing pointer to it to dma_set_attr(), just set the bits.
>>
>> 2. It brings safeness and checking for const correctness because the
>> attributes are passed by value.
>
>
> .. why not go the next step a do an enum? Perhaps that should be mentioned
> as part of the description?
These are additive flags so to me this would look a little bit weird:
enum dma_attr {
DMA_ATTR_WRITE_BARRIER = 0x1,
DMA_ATTR_WEAK_ORDERING = 0x2,
DMA_ATTR_WRITE_COMBINE = 0x4,
DMA_ATTR_NON_CONSISTENT = 0x8,
...
}
It doesn't really look like enumeration.
Best regards,
Krzysztof
WARNING: multiple messages have this Message-ID (diff)
From: k.kozlowski@samsung.com (Krzysztof Kozlowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v2] dma-mapping: Use unsigned long for dma_attrs
Date: Wed, 01 Jun 2016 08:08:11 +0200 [thread overview]
Message-ID: <574E7BCB.6040505@samsung.com> (raw)
In-Reply-To: <20160531181533.GD11300@char.us.oracle.com>
On 05/31/2016 08:15 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
>> The dma-mapping core and the implementations do not change the
>> DMA attributes passed by pointer. Thus the pointer can point to const
>> data. However the attributes do not have to be a bitfield. Instead
>> unsigned long will do fine:
>>
>> 1. This is just simpler. Both in terms of reading the code and setting
>> attributes. Instead of initializing local attributes on the stack and
>> passing pointer to it to dma_set_attr(), just set the bits.
>>
>> 2. It brings safeness and checking for const correctness because the
>> attributes are passed by value.
>
>
> .. why not go the next step a do an enum? Perhaps that should be mentioned
> as part of the description?
These are additive flags so to me this would look a little bit weird:
enum dma_attr {
DMA_ATTR_WRITE_BARRIER = 0x1,
DMA_ATTR_WEAK_ORDERING = 0x2,
DMA_ATTR_WRITE_COMBINE = 0x4,
DMA_ATTR_NON_CONSISTENT = 0x8,
...
}
It doesn't really look like enumeration.
Best regards,
Krzysztof
next prev parent reply other threads:[~2016-06-01 6:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-30 11:54 [RFC v2] Change dma_attrs from bitfield to unsigned long Krzysztof Kozlowski
2016-05-30 11:54 ` Krzysztof Kozlowski
[not found] ` <1464609246-6948-1-git-send-email-k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-05-30 11:54 ` [RFC v2] dma-mapping: Use unsigned long for dma_attrs Krzysztof Kozlowski
2016-05-30 11:54 ` Krzysztof Kozlowski
2016-05-30 11:54 ` Krzysztof Kozlowski
2016-05-31 17:04 ` Christoph Hellwig
2016-05-31 17:04 ` Christoph Hellwig
2016-05-31 17:04 ` Christoph Hellwig
2016-05-31 17:04 ` Christoph Hellwig
2016-06-01 5:36 ` Krzysztof Kozlowski
2016-06-01 5:36 ` Krzysztof Kozlowski
2016-06-01 7:51 ` Christoph Hellwig
2016-06-01 7:51 ` Christoph Hellwig
2016-06-01 7:51 ` Christoph Hellwig
2016-06-01 7:51 ` Christoph Hellwig
2016-06-01 5:36 ` Krzysztof Kozlowski
2016-05-31 18:15 ` Konrad Rzeszutek Wilk
2016-05-31 18:15 ` Konrad Rzeszutek Wilk
2016-05-31 18:15 ` Konrad Rzeszutek Wilk
2016-05-31 18:15 ` Konrad Rzeszutek Wilk
2016-06-01 6:08 ` Krzysztof Kozlowski
2016-06-01 6:08 ` Krzysztof Kozlowski [this message]
2016-06-01 6:08 ` Krzysztof Kozlowski
2016-05-30 11:54 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=574E7BCB.6040505@samsung.com \
--to=k.kozlowski@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=b.zolnierkie@samsung.com \
--cc=catalin.marinas@arm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=luto@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=sstabellini@kernel.org \
--cc=will.deacon@arm.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.