From: Arnd Bergmann <arnd@arndb.de> To: soc@kernel.org Cc: Arnd Bergmann <arnd@arndb.de>, Russell King <linux@armlinux.org.uk>, Dan Williams <dan.j.williams@intel.com>, Vinod Koul <vkoul@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org, linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org Subject: [PATCH 3/7] dma: iop-adma: use correct printk format strings Date: Fri, 9 Aug 2019 18:33:17 +0200 [thread overview] Message-ID: <20190809163334.489360-3-arnd@arndb.de> (raw) In-Reply-To: <20190809163334.489360-1-arnd@arndb.de> When compile-testing on other architectures, we get lots of warnings about incorrect format strings, like: drivers/dma/iop-adma.c: In function 'iop_adma_alloc_slots': drivers/dma/iop-adma.c:307:6: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=] drivers/dma/iop-adma.c: In function 'iop_adma_prep_dma_memcpy': >> drivers/dma/iop-adma.c:518:40: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=] Use %zu for printing size_t as required, and cast the dma_addr_t arguments to 'u64' for printing with %llx. Ideally this should use the %pad format string, but that requires an lvalue argument that doesn't work here. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/dma/iop-adma.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c index 7857b54770d1..aebdd671651a 100644 --- a/drivers/dma/iop-adma.c +++ b/drivers/dma/iop-adma.c @@ -117,9 +117,9 @@ static void __iop_adma_slot_cleanup(struct iop_adma_chan *iop_chan) list_for_each_entry_safe(iter, _iter, &iop_chan->chain, chain_node) { pr_debug("\tcookie: %d slot: %d busy: %d " - "this_desc: %#x next_desc: %#x ack: %d\n", + "this_desc: %#x next_desc: %#llx ack: %d\n", iter->async_tx.cookie, iter->idx, busy, - iter->async_tx.phys, iop_desc_get_next_desc(iter), + iter->async_tx.phys, (u64)iop_desc_get_next_desc(iter), async_tx_test_ack(&iter->async_tx)); prefetch(_iter); prefetch(&_iter->async_tx); @@ -307,9 +307,9 @@ iop_adma_alloc_slots(struct iop_adma_chan *iop_chan, int num_slots, int i; dev_dbg(iop_chan->device->common.dev, "allocated slot: %d " - "(desc %p phys: %#x) slots_per_op %d\n", + "(desc %p phys: %#llx) slots_per_op %d\n", iter->idx, iter->hw_desc, - iter->async_tx.phys, slots_per_op); + (u64)iter->async_tx.phys, slots_per_op); /* pre-ack all but the last descriptor */ if (num_slots != slots_per_op) @@ -517,7 +517,7 @@ iop_adma_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dma_dest, return NULL; BUG_ON(len > IOP_ADMA_MAX_BYTE_COUNT); - dev_dbg(iop_chan->device->common.dev, "%s len: %u\n", + dev_dbg(iop_chan->device->common.dev, "%s len: %zu\n", __func__, len); spin_lock_bh(&iop_chan->lock); @@ -550,7 +550,7 @@ iop_adma_prep_dma_xor(struct dma_chan *chan, dma_addr_t dma_dest, BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT); dev_dbg(iop_chan->device->common.dev, - "%s src_cnt: %d len: %u flags: %lx\n", + "%s src_cnt: %d len: %zu flags: %lx\n", __func__, src_cnt, len, flags); spin_lock_bh(&iop_chan->lock); @@ -583,7 +583,7 @@ iop_adma_prep_dma_xor_val(struct dma_chan *chan, dma_addr_t *dma_src, if (unlikely(!len)) return NULL; - dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n", + dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n", __func__, src_cnt, len); spin_lock_bh(&iop_chan->lock); @@ -621,7 +621,7 @@ iop_adma_prep_dma_pq(struct dma_chan *chan, dma_addr_t *dst, dma_addr_t *src, BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT); dev_dbg(iop_chan->device->common.dev, - "%s src_cnt: %d len: %u flags: %lx\n", + "%s src_cnt: %d len: %zu flags: %lx\n", __func__, src_cnt, len, flags); if (dmaf_p_disabled_continue(flags)) @@ -684,7 +684,7 @@ iop_adma_prep_dma_pq_val(struct dma_chan *chan, dma_addr_t *pq, dma_addr_t *src, return NULL; BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT); - dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n", + dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n", __func__, src_cnt, len); spin_lock_bh(&iop_chan->lock); -- 2.20.0
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de> To: soc@kernel.org Cc: Arnd Bergmann <arnd@arndb.de>, linux-gpio@vger.kernel.org, Linus Walleij <linus.walleij@linaro.org>, Russell King <linux@armlinux.org.uk>, linux-kernel@vger.kernel.org, Bartosz Golaszewski <bgolaszewski@baylibre.com>, Vinod Koul <vkoul@kernel.org>, linux-i2c@vger.kernel.org, dmaengine@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>, linux-arm-kernel@lists.infradead.org Subject: [PATCH 3/7] dma: iop-adma: use correct printk format strings Date: Fri, 9 Aug 2019 18:33:17 +0200 [thread overview] Message-ID: <20190809163334.489360-3-arnd@arndb.de> (raw) In-Reply-To: <20190809163334.489360-1-arnd@arndb.de> When compile-testing on other architectures, we get lots of warnings about incorrect format strings, like: drivers/dma/iop-adma.c: In function 'iop_adma_alloc_slots': drivers/dma/iop-adma.c:307:6: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=] drivers/dma/iop-adma.c: In function 'iop_adma_prep_dma_memcpy': >> drivers/dma/iop-adma.c:518:40: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=] Use %zu for printing size_t as required, and cast the dma_addr_t arguments to 'u64' for printing with %llx. Ideally this should use the %pad format string, but that requires an lvalue argument that doesn't work here. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/dma/iop-adma.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c index 7857b54770d1..aebdd671651a 100644 --- a/drivers/dma/iop-adma.c +++ b/drivers/dma/iop-adma.c @@ -117,9 +117,9 @@ static void __iop_adma_slot_cleanup(struct iop_adma_chan *iop_chan) list_for_each_entry_safe(iter, _iter, &iop_chan->chain, chain_node) { pr_debug("\tcookie: %d slot: %d busy: %d " - "this_desc: %#x next_desc: %#x ack: %d\n", + "this_desc: %#x next_desc: %#llx ack: %d\n", iter->async_tx.cookie, iter->idx, busy, - iter->async_tx.phys, iop_desc_get_next_desc(iter), + iter->async_tx.phys, (u64)iop_desc_get_next_desc(iter), async_tx_test_ack(&iter->async_tx)); prefetch(_iter); prefetch(&_iter->async_tx); @@ -307,9 +307,9 @@ iop_adma_alloc_slots(struct iop_adma_chan *iop_chan, int num_slots, int i; dev_dbg(iop_chan->device->common.dev, "allocated slot: %d " - "(desc %p phys: %#x) slots_per_op %d\n", + "(desc %p phys: %#llx) slots_per_op %d\n", iter->idx, iter->hw_desc, - iter->async_tx.phys, slots_per_op); + (u64)iter->async_tx.phys, slots_per_op); /* pre-ack all but the last descriptor */ if (num_slots != slots_per_op) @@ -517,7 +517,7 @@ iop_adma_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dma_dest, return NULL; BUG_ON(len > IOP_ADMA_MAX_BYTE_COUNT); - dev_dbg(iop_chan->device->common.dev, "%s len: %u\n", + dev_dbg(iop_chan->device->common.dev, "%s len: %zu\n", __func__, len); spin_lock_bh(&iop_chan->lock); @@ -550,7 +550,7 @@ iop_adma_prep_dma_xor(struct dma_chan *chan, dma_addr_t dma_dest, BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT); dev_dbg(iop_chan->device->common.dev, - "%s src_cnt: %d len: %u flags: %lx\n", + "%s src_cnt: %d len: %zu flags: %lx\n", __func__, src_cnt, len, flags); spin_lock_bh(&iop_chan->lock); @@ -583,7 +583,7 @@ iop_adma_prep_dma_xor_val(struct dma_chan *chan, dma_addr_t *dma_src, if (unlikely(!len)) return NULL; - dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n", + dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n", __func__, src_cnt, len); spin_lock_bh(&iop_chan->lock); @@ -621,7 +621,7 @@ iop_adma_prep_dma_pq(struct dma_chan *chan, dma_addr_t *dst, dma_addr_t *src, BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT); dev_dbg(iop_chan->device->common.dev, - "%s src_cnt: %d len: %u flags: %lx\n", + "%s src_cnt: %d len: %zu flags: %lx\n", __func__, src_cnt, len, flags); if (dmaf_p_disabled_continue(flags)) @@ -684,7 +684,7 @@ iop_adma_prep_dma_pq_val(struct dma_chan *chan, dma_addr_t *pq, dma_addr_t *src, return NULL; BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT); - dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n", + dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n", __func__, src_cnt, len); spin_lock_bh(&iop_chan->lock); -- 2.20.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-08-09 16:34 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-09 16:29 [PATCH 0/7] ARM: preparation for multiplatform iop32x Arnd Bergmann 2019-08-09 16:33 ` [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support Arnd Bergmann 2019-08-09 16:33 ` [PATCH 2/7] dma: iop-adma: include prefetch.h Arnd Bergmann 2019-08-09 16:33 ` Arnd Bergmann 2019-08-09 16:33 ` Arnd Bergmann 2019-08-13 4:33 ` Vinod Koul 2019-08-13 4:33 ` Vinod Koul 2019-08-14 15:29 ` Arnd Bergmann 2019-08-14 15:29 ` Arnd Bergmann 2019-08-09 16:33 ` Arnd Bergmann [this message] 2019-08-09 16:33 ` [PATCH 3/7] dma: iop-adma: use correct printk format strings Arnd Bergmann 2019-08-13 4:33 ` Vinod Koul 2019-08-13 4:33 ` Vinod Koul 2019-08-09 16:33 ` [PATCH 4/7] dma: iop-adma: allow building without platform headers Arnd Bergmann 2019-08-09 16:33 ` Arnd Bergmann 2019-08-09 16:33 ` [PATCH 5/7] ARM: xscale: fix multi-cpu compilation Arnd Bergmann 2019-08-09 16:33 ` Arnd Bergmann 2019-08-23 7:44 ` Linus Walleij 2019-08-23 7:44 ` Linus Walleij 2019-08-09 16:33 ` [PATCH 6/7] ARM: iop32x: make mach/uncompress.h independent of mach/hardware.h Arnd Bergmann 2019-08-09 16:33 ` Arnd Bergmann 2019-08-09 16:33 ` [PATCH 7/7] ARM: iop32x: merge everything into mach-iop32x/ Arnd Bergmann 2019-08-09 16:33 ` Arnd Bergmann 2019-08-09 16:57 ` [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support Wolfram Sang 2019-08-09 16:57 ` Wolfram Sang 2019-08-09 18:34 ` Dan Williams 2019-08-09 18:34 ` Dan Williams 2019-08-09 18:36 ` Russell King - ARM Linux admin 2019-08-09 18:36 ` Russell King - ARM Linux admin 2019-08-09 19:43 ` Dan Williams 2019-08-09 19:43 ` Dan Williams 2019-08-12 9:44 ` Martin Michlmayr 2019-08-12 9:44 ` Martin Michlmayr 2019-08-14 8:36 ` Linus Walleij 2019-08-14 8:36 ` Linus Walleij 2019-08-14 10:48 ` Arnd Bergmann 2019-08-14 10:48 ` Arnd Bergmann 2019-08-16 15:42 ` Aaro Koskinen 2019-08-16 15:42 ` Aaro Koskinen 2019-08-16 15:58 ` Russell King - ARM Linux admin 2019-08-16 15:58 ` Russell King - ARM Linux admin 2019-08-16 16:15 ` Aaro Koskinen 2019-08-16 16:15 ` Aaro Koskinen 2019-08-09 16:38 ` [PATCH 0/7] ARM: preparation for multiplatform iop32x Lennert Buytenhek 2019-08-15 12:50 ` Arnd Bergmann
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=20190809163334.489360-3-arnd@arndb.de \ --to=arnd@arndb.de \ --cc=bgolaszewski@baylibre.com \ --cc=dan.j.williams@intel.com \ --cc=dmaengine@vger.kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=soc@kernel.org \ --cc=vkoul@kernel.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: linkBe 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.