From: rdunlap@infradead.org (Randy Dunlap)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1] dma: imx-sdma: add support for sdma memory copy
Date: Wed, 23 Apr 2014 10:31:53 -0700 [thread overview]
Message-ID: <5357F909.7070205@infradead.org> (raw)
In-Reply-To: <1398165864.11914.241.camel@smile.fi.intel.com>
On 04/22/14 04:24, Andy Shevchenko wrote:
> On Tue, 2014-04-22 at 18:51 +0800, Robin Gong wrote:
>> On Tue, Apr 22, 2014 at 10:28:05AM +0000, Shevchenko, Andriy wrote:
>>> On Fri, 2014-04-18 at 17:41 +0800, Robin Gong wrote:
>>>> On Thu, Apr 17, 2014 at 10:24:50AM +0000, Shevchenko, Andriy wrote:
>>>>> On Thu, 2014-04-17 at 18:01 +0800, Robin Gong wrote:
>>>
>>> []
>>>
>>>>>> + dev_dbg(sdma->dev, "memcpy: %x->%x, len=%d, channel=%d.\n",
>>>>>
>>>>> %pad for dma_addr_t variables.
>>>>>
>>>> Yes, %x here is not proper, will be %#llx here to align with others similar
>>>> code in this file.
>>>
>>> Why %#llx? You don't need the specific casting since kernel has special
>>> specifiers for phys_addr_t and dma_addr_t and their derivatives (see
>>> Documentation/printk-formats.txt)
>>>
>> I think both are ok, why I choose %llx is only for align the code style,
>
> Yes, but it was started being developed earlier than kernel gains the
> feature.
>
>> you
>> can find the same code in sdma_prep_dma_cyclic function. below description also
>> copy from Documentation/printk-formats.txt:
>>
>>
>> If <type> is dependent on a config option for its size (e.g., sector_t,
>> blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
>> for its size (e.g., tcflag_t), use a format specifier of its largest
>> possible type and explicitly cast to it. Example:
>>
>> printk("test: sector number/total blocks: %llu/%llu\n",
>> (unsigned long long)sector, (unsigned long long)blockcount);
>
> Yeah, I think it requires to be updated accordingly to last changes
> regarding to new specifiers.
>
> +Cc Randy. Randy, do you think is a matter of fact that we have to
> update that paragraph somehow and recommend to prefer special specifiers
> over explicit casting to longest possible type?
Yes, I agree, if there is a printk format specifier that supports a certain type
to be printed, we should prefer to use that instead of the generic casting method.
IMO, the cast to (long long) or (unsigned long long) or (u64) or (s64) should be a last
resort safe method.
>>>>>> + dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
>>>>>> + i, count, sg_src->dma_address,
>>>>>
>>>>> %pad for dma_addr_t.
>>>>>
>>>> Accept the idea, same as the above.
>>>
>>> Same as above.
>
>
--
~Randy
prev parent reply other threads:[~2014-04-23 17:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-17 10:01 [PATCH v1] dma: imx-sdma: add support for sdma memory copy Robin Gong
2014-04-17 10:24 ` Shevchenko, Andriy
2014-04-18 9:41 ` Robin Gong
2014-04-22 10:28 ` Shevchenko, Andriy
2014-04-22 10:51 ` Robin Gong
2014-04-22 11:24 ` Andy Shevchenko
2014-04-23 17:31 ` Randy Dunlap [this message]
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=5357F909.7070205@infradead.org \
--to=rdunlap@infradead.org \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).