All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>, Arnd Bergmann <arnd@arndb.de>,
	linux-doc@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Joerg Roedel <joro@8bytes.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Will Deacon <will.deacon@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org,
	linux-samsung-soc@vger.kernel.org, sstabellini@kernel.org,
	Andy Lutomirski <luto@kernel.org>,
	xen-devel@lists.xenproject.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	linux-arm-kernel@lists.infradead.org,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [RFC v2] dma-mapping: Use unsigned long for dma_attrs
Date: Wed, 01 Jun 2016 07:36:42 +0200	[thread overview]
Message-ID: <574E746A.2030806__5062.46998343176$1464759493$gmane$org@samsung.com> (raw)
In-Reply-To: <20160531170420.GB25366@infradead.org>

On 05/31/2016 07:04 PM, Christoph Hellwig 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.
>>
>> Please have in mind that this is RFC, not finished yet.  Only ARM and
>> ARM64 are fixed (and not everywhere).
>> However other API users also have to be converted which is quite
>> intrusive.  I would rather avoid it until the overall approach is
>> accepted.
> 
> This looks great!  Please continue doing the full conversion.
> 
>> +/**
>> + * List of possible attributes associated with a DMA mapping. The semantics
>> + * of each attribute should be defined in Documentation/DMA-attributes.txt.
>> + */
>> +#define DMA_ATTR_WRITE_BARRIER		BIT(1)
>> +#define DMA_ATTR_WEAK_ORDERING		BIT(2)
>> +#define DMA_ATTR_WRITE_COMBINE		BIT(3)
>> +#define DMA_ATTR_NON_CONSISTENT		BIT(4)
>> +#define DMA_ATTR_NO_KERNEL_MAPPING	BIT(5)
>> +#define DMA_ATTR_SKIP_CPU_SYNC		BIT(6)
>> +#define DMA_ATTR_FORCE_CONTIGUOUS	BIT(7)
>> +#define DMA_ATTR_ALLOC_SINGLE_PAGES	BIT(8)
> 
> No really for this patch, but I would much prefer to document them next
> to the code in the long run.  Also I really think these BIT() macros
> are a distraction compared to the (1 << N) notation.

Not much difference to me but maybe plain number:
...	0x01u
...	0x02u
?

> 
>> +/**
>> + * dma_get_attr - check for a specific attribute
>> + * @attr: attribute to look for
>> + * @attrs: attributes to check within
>> + */
>> +static inline bool dma_get_attr(unsigned long attr, unsigned long attrs)
>> +{
>> +	return !!(attr & attrs);
>> +}
> 
> I'd just kill this helper, much easier to simply open code it in the
> caller.

Keeping it for now helps reducing the number of changes in the patch.
The patch will be quite big as it has to replace all the uses atomically.

I can get rid of the helper in consecutive patch.

Best regards,
Krzysztof



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-06-01  5:36 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
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-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 [this message]
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-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
2016-06-01  6:08       ` Krzysztof Kozlowski
2016-05-31 18:15   ` Konrad Rzeszutek Wilk

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='574E746A.2030806__5062.46998343176$1464759493$gmane$org@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=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.